-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed 2024h2 flagship goal: Rust for Linux #3658
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for preparing this Niko, a few comments below.
@ojeda I think I addressed your comments, please take a look at the intro. |
Hmm... I don't see them here, did you push? |
| ↳ implementation | [Xiang][] | ![Volunteer][] | | ||
| ↳ stabilization | [Xiang][] | ![Volunteer][] | | ||
| `asm_goto` | | | | ||
| ↳ ~~implementation~~ | - | ![Complete][] | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
### Code-generation features and compiler options | ||
|
||
The RFL project requires various code-generation options. Some of these are related to custom features of the kernel, such as [X18 support][#748] but others are codegen options like sanitizers and the like. Some subset of the options listed on [RFL#2][] will need to be stabilized to support being built with all required configurations, but working out the precise set will require more effort. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 cfg
s and not the codegen options there, I guess)
Thanks for clarifying!
### Labeled goto in inline assembler and extended `offset_of!` support | ||
|
||
These are two smaller extensions required by the Rust-for-Linux kernel support. | ||
Both have been implemented but more experience and/or may be needed before stabilization is accepted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something is missing in this sentence after "and/or". Or maybe the "and/or" shouldn't be there?
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. |
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? |
Clar: Delayed response, but the new process is having one master RFC (#3672).
|
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:
self
types and unsizeable smart pointers, thus permitting ergonomic support for in-place linked lists on stable;offset_of!
support, needed for various bts of low-level coding;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