Proposed 2024h2 flagship goal: Rust for Linux

[nikomatsakis]

This is a proposed flagship goal for 2024h2 covering Rust for Linux. You can read more about the project goal slate and its associated process here. This RFC is prepared using the project goal template, which differs from the typical RFC template.

The overall goal is resolving the biggest blockers to Linux building on stable Rust via the following steps:

• stabilizing support for arbitrary self types and unsizeable smart pointers, thus permitting ergonomic support for in-place linked lists on stable;
• stabilizing features for labeled goto in inline assembler and extended offset_of! support, needed for various bts of low-level coding;
• adding Rust For Linux project on Rust CI, thus ensuring we don't accidentally cause regressions for this highly visible project (done!);
• stabilizing support for pointers to statics in constants, permitting the construction of vtables for kernel modules;
• code-generation features and compiler options, allowing Rust to match the compilers given to gcc/clang when building the kernel;
• and, if possible, stabilize options for building core/alloc with fewer features, allowing the kernel to forbid infallible allocation and other aspects of the standard libraries that it does not want (this requires further investigation).

Approving this goal implies agreement from the Lang, Compiler, and Libs-API teams to the items marked as in the table of work items, along with potentially other design meetings as needed.

Rendered

[ojeda]

Thanks for preparing this Niko, a few comments below.

[nikomatsakis]

@ojeda I think I addressed your comments, please take a look at the intro.

[ojeda]

Hmm... I don't see them here, did you push?

[nbdd0121]

I am happy to also own the implementation part of asm_goto. In my implementation #119365 I leave out the fallthrough block, and I am happy to implement that if experiment in the kernel shows that it is useful.

[wesleywiser]

A number of these options (for example the reserve x18 option) need to be set when building the parts of the standard library that RfL uses. If the "stabilize options for building core/alloc with fewer features" step is achieved, that provides a natural way to configure those options.

If the step is not achieved, do we have plan on record for making RfL able to use these codegen options? It might be good to at least have a fallback option identified to maximize the value delivered from the rest of the work (for example, we could commit to shipping a set of *-linux-kernel targets at Tier 2 or above that have the appropriate codegen options set).

[ojeda]

that provides a natural way to configure those options.

Do you mean they would be inherited for the rest of the code so they would not need to be passed to other rustc calls? Or am I misunderstanding?

In general, I feel that the less special core and alloc are, and the more flexibility on codegen there is, the better it would be for the kernel and similar projects.

So being able to compile core and alloc just (almost) like any other crate (like we do now), and being able to customize it as much as possible (as much as C compilers allow) with simple CLI flags on rustc, is ideal.

Having fixed codegen options in built-in targets that can only be tweaked on the Rust side sounds too rigid, and we would also have the issue of the potentially many combinations of targets.

[wesleywiser]

No, what I mean is that if we have a stable option to allow the user to build standard library crates, I would think that would naturally include the ability for a user to specify additional codegen flags during that compilation. Thus, "how does RfL enable things like KCFI, reserve x18, etc?" is resolved.

If we do not have a stable way for users to build the standard library crates, we should consider providing some other way for RfL to get the standard library crates you need without use of nightly features to build them.

[ojeda]

Thus, "how does RfL enable things like KCFI, reserve x18, etc?" is resolved.

But why would it be resolved? We would still need to pass the flags to other translation units / crates, no? (That is why I was asking whether you meant that somehow those flags got inherited automatically if a TU depended on a core that was compiled with them.)

[wesleywiser]

If you can you build the standard library (or parts there of) on a stable compiler, I'm assuming you can just pass along -Creserve-x18 or whatever you need 🙂

My broader point though is that if we've done the work to enable you to move off nightly features for these other things, we should also provide some path for you to use libcore, etc with the required codegen options in a stable way as well.

[ojeda]

Ah, if the options are stable already, of course! (and, for us, just using the flags normally like we would for any other TU is ideal). I thought you meant that, without having stabilized those flags, somehow solving the issue for building the standard library with them in a stable way would provide a solution for the rest of the code (and thus the inheriting question).

Agreed that, if the codegen flags are stabilized, then we need a stable way to build core/alloc with those too. (The text in the other section could have explicitly mentioned the flags too to be more clear, i.e. one could read that we only need to use cfgs and not the codegen options there, I guess)

Thanks for clarifying!

[tmccombs]

I think something is missing in this sentence after "and/or". Or maybe the "and/or" shouldn't be there?

[nikomatsakis]

Upon reflection, I've decided to change the process for approving project goals. I'm going to close this RFC, but the content is still correct.

[clarfonthey]

I assume that "I've decided to change the process for approving project goals" here means that you're not the only one who decided to make that change, and it was more a shared decision from multiple people.

What is the new process?

[nikomatsakis]

Clar: Delayed response, but the new process is having one master RFC (#3672).