Review of 863bd2e4f203:

• ✔️ Commit 863bd2e: Looks fine!

Looks fine to me. I let others comment in case someone thinks about any other pros/cons.

Off-topic: things would look better if the restriction on the entry points being in the root crate is lifted. Alas...

I like that this is moving to its own directory.

Another thought I had some time back: can we move this to a directory outside rust/, perhaps some other subdirectory under tools/? My idea here is to avoid confusing reviewers that may think that this code is going to be part of the kernel; by moving this out we can claim that code in rust/ will likely end up in the kernel, but code in say tools/rust (or whatever place in find for it) is only used at compile time and will never be in the kernel.

WDYT?

I don't think anything in tools is currently required for building the kernel? Maybe sceipts?

But anyway I think it's the best to keep it within Rust directory, because even though itself is not compiled into the kernel, it does generate code that's compiled, and many of which is from templates.

I don't think anything in tools is currently required for building the kernel?

There is objtool for instance, but yeah, I am not sure what is the precise requirement between one and the other place. Perhaps the perceived complexity? :-)

From a quick look at history, there was not much fuss when creating the tools folder, it was simply done to move perf out of Documentation/.

Another thought I had some time back: can we move this to a directory outside rust/, perhaps some other subdirectory under tools/? My idea here is to avoid confusing reviewers that may think that this code is going to be part of the kernel; by moving this out we can claim that code in rust/ will likely end up in the kernel, but code in say tools/rust (or whatever place in find for it) is only used at compile time and will never be in the kernel.

WDYT?

I thought about this when I set the initial support, not just for procedural macros but also other bits like the bindings etc. My idea was that, at least initially, it would be best to "contain" Rust as much as possible within rust/ (obviously samples/, drivers/ and a few other bits in the infrastructure need to go outside).

For kernel code, it seems like that is still the right choice.

For procedural macros, I think it makes the most sense them close to the code too, since they are, after all, very tied to it. They not only generate Rust code in-place (in contrast with other host programs that generate e.g. a new C file or header); they also parse some kind of input (whether Rust code or not) that comes from Rust source files themselves too (rather than, e.g. from a non-C file).

Is this approach fine for the kernel? A few places also put their own host binaries that generate C code alongside the kernel C code, e.g. drivers/tty/vt/conmakehash.c or quite a few in arch/ etc. So keeping the procedural macros close to the code seems fine.

One could argue that e.g. objtool is not really independent either from the code either, and that it is as "kernel-wide" as our procedural macros such as module!. But I see objtool and similar tools/scripts as extra steps/phases in the build process, and they do not transform some input in-place in existing C files.

LGTM!