On Fri, Jun 07, 2024 at 09:43:29AM +0000, Alice Ryhl wrote:
Peter Zijlstra [off-list ref] wrote:
quoted
On Thu, Jun 06, 2024 at 09:09:00PM +0200, Miguel Ojeda wrote:
quoted
On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra [off-list ref] wrote:
quoted
This is absolutely unreadable gibberish -- how am I supposed to keep
this in sync with the rest of the static_call infrastructure?
Yeah, they are macros, which look different from "normal" Rust code.
Macros like CPP ?
Yes, this patch series uses declarative macros, which are the closest
that Rust has to the C preprocessor. They are powerful, but just like
CPP, they can become pretty complicated and hard to read if you are
doing something non-trivial.
The macro_rules! block is how you define a new declarative macro.
I'm sorry, but 30+ years of reading ! as NOT (or factorial) isn't going
to go away. So I'm reading your macros do NOT rule.
The ($name:ident($($args:expr),* $(,)?)) part defines the arguments to
the declarative macro. This syntax means:
1. The input starts with any identifier, which we call $name.
2. Then there must be a ( token.
The above exaple fails, because the next token is :ident, whatever the
heck that might be. Also, extra points for line-noise due to lack of
whitespace.
So for example, you might invoke the macro like this:
static_call!(tp_func_my_tracepoint(__data, &mut my_task_struct));
static_call NOT (blah dog blah);
Inside the macro, you will see things such as:
$crate::macros::paste! { $crate::bindings:: [<__SCK__ $name >]; }
The Rust syntax for invoking a macro has an exclamation mark after the
Like I said before, the creator of Rust must've been an esoteric
language freak and must've wanted to make this unreadable on purpose :/
Also, why the white space beteen the :: scope operator and the [< thing?
that's just weird. I would then expect the output to be:
...::bindings:: __SCK__my_static_key
name, so you know that $crate::macros::paste is a macro. The `paste`
macro just emits its input unchanged, except that any identifiers
between [< and >] are concatenated into a single identifier. So if $name
is my_static_key, then the above invocation of paste! emits:
$crate::bindings::__SCK__my_static_key;
But it doesn't, so it isn't unmodified, it seems to strip whitespace.
The $crate::bindings module is where the output of bindgen goes, so this
should correspond to the C symbol called __SCK__my_static_key.
quoted
quoted
Is there something we could do to help here? I think Alice and others
would be happy to explain how it works and/or help maintain it in the
future if you prefer.
Write a new language that looks more like C -- pretty please ? :-)
Mostly I would just really like you to just use arm/jump_label.h,
they're inline functions and should be doable with IR, no weirdo CPP
involved in this case.
I assume that you're referring to static_key_false here? I don't think
that function can be exposed using IR because it passes the function
argument called key as an "i" argument to an inline assembly block. Any
attempt to compile static_key_false without knowing the value of key at
compile time will surely fail to compile with the
invalid operand for inline asm constraint 'i'
error.
You can have clang read the header files and compile them into
Intermediate-Representation, and have it splice the lot into the Rust
crap's IR and voila, compile time.
You just need to extend the rust thing to be able to consume C header
files.