4 ms·

The one point that stuck out to me is > At the present time, we require certain nightly features. That is, features that are not available in the stable compil

The one point that stuck out to me is > At the present time, we require certain nightly features. That is, features that are not available in the stable compiler. Nevertheless, we aim to remove this restriction within a year by either `rustc` landing the features in stable or removing our usage of them otherwise. Using unstable features in something like the Linux kernel just seems like a bad idea. Why not wait until Rust is a little more matured, and doesn't need to use nightly features?

steveklabnik 5y ago
They might. There are five things that they're using that they can't work around: One is going to be stable in Rust 1.52.0, the next release of Rust. This will happen before the next kernel release, so it barely counts. It's also a documentation tooling feature. One is related to symbol mangling, and so in theory could be worked around I'd imagine, but is landing soon enough they don't think it's worth it. The final three are related to each other; two of them look like they're being stable pretty soon, and the third, while it's less clear on timeline, is one pretty small thing. So, the answer is basically that the exposure here is pretty small. How much that matters is a social question as much as a technical one. While "unstable" is a binary designation, within it is a spectrum of unstability. "This feature has no path to stabilization" to "this will be stable in the next Rust" and all things in between. Maybe allowing some unstable things that are closer to the latter is acceptable, maybe not.
- Gadiguibou 5y ago
  I'm curious about what those specific features are. Could you tell me their names? I'd like to go read up on them a bit more.
  - hmfrh 5y ago
    A list is found here[1]. [1]: https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2
    - Gadiguibou 5y ago
      Thank you!
  - imjasonmiller 5y ago
    See https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2

steveklabnik 5y ago

They might. There are five things that they're using that they can't work around: One is going to be stable in Rust 1.52.0, the next release of Rust. This will happen before the next kernel release, so it barely counts. It's also a documentation tooling feature. One is related to symbol mangling, and so in theory could be worked around I'd imagine, but is landing soon enough they don't think it's worth it. The final three are related to each other; two of them look like they're being stable pretty soon, and the third, while it's less clear on timeline, is one pretty small thing. So, the answer is basically that the exposure here is pretty small. How much that matters is a social question as much as a technical one. While "unstable" is a binary designation, within it is a spectrum of unstability. "This feature has no path to stabilization" to "this will be stable in the next Rust" and all things in between. Maybe allowing some unstable things that are closer to the latter is acceptable, maybe not.

Gadiguibou 5y ago
I'm curious about what those specific features are. Could you tell me their names? I'd like to go read up on them a bit more.
- hmfrh 5y ago
  A list is found here[1]. [1]: https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2
  - Gadiguibou 5y ago
    Thank you!
- imjasonmiller 5y ago
  See https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2