Skip to content
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

Closed
wants to merge 5 commits into from

Conversation

nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Jun 14, 2024

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 Team in the table of work items, along with potentially other design meetings as needed.

Rendered

@nikomatsakis nikomatsakis added T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. labels Jun 14, 2024
Copy link

@ojeda ojeda left a 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.

text/0000-rust-for-linux-project-goal-2024h2.md Outdated Show resolved Hide resolved
text/0000-rust-for-linux-project-goal-2024h2.md Outdated Show resolved Hide resolved
text/0000-rust-for-linux-project-goal-2024h2.md Outdated Show resolved Hide resolved
@nikomatsakis
Copy link
Contributor Author

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

@ojeda
Copy link

ojeda commented Jun 18, 2024

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

| ↳ implementation | [Xiang][] | ![Volunteer][] |
| ↳ stabilization | [Xiang][] | ![Volunteer][] |
| `asm_goto` | | |
| ↳ ~~implementation~~ | - | ![Complete][] |
Copy link

@nbdd0121 nbdd0121 Jun 19, 2024

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.
Copy link
Member

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).

Copy link

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.

Copy link
Member

@wesleywiser wesleywiser Jun 26, 2024

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.

Copy link

@ojeda ojeda Jun 26, 2024

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.)

Copy link
Member

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.

Copy link

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 cfgs 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.

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?

@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor

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?

@clarfonthey clarfonthey mentioned this pull request Jun 26, 2024
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Jul 11, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-lang Relevant to the language team, which will review and decide on the RFC. T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants