← Back to context

Comment by jenadine

2 months ago

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler.

Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)

Don't the C parts of Linux heavily depend on GCC extensions too? Seems depending on specific compiler features isn't really a blocker.

  • The difference probably is that GCC extensions have been stable for decades. Meanwhile Rust experimental features have breaking changes between versions. So a Rust version 6 months from now likely won't be able to compile the kernel we have today, but a GCC version in a decade will still work.

> Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel)

It's trivial to install a specific version of the toolchain though.

  • You don't generally need specific versions of GCC or Clang to build it I'm pretty sure.

    • > You don't generally need specific versions of GCC or Clang to build it I'm pretty sure.

      You need a C11 compiler these days with loads of non-standard extensions. Note, for a very long time, one couldn't compile the Linux kernel with clang because it lacked this GCC specific behavior.

      I'm not really sure you can turn around and say -- Oh, but now we feel differently about the C standard -- given how much is still non-standard. For instance, I don't believe Intel's C compiler will compile the kernel, etc.

What if I told you… there was a simple, constant environment variable you could set to make the stable compiler forget it isn’t a nightly?

  • When it comes to nightly features use, it is good to note that a stable compiler, a nightly corresponding to the date beta for that stable was branched out and an arbitrary nightly are different. A branched-off nightly might have had beta back ports for fixing stable features that the nightly will not have, and a nightly feature that is subtly broken on stable but isn't used in std will not have received a backport. So using nightly feature on stable might mean every now and then skipping a stable version, and using a nightly compiler means having to do thorough testing after updating on arbitrary days. Any given nightly has high chances of being fine, but every update brings the possibility of bugs.

  • the point is unstable features aren't guaranteed to not break after a compiler update. hence the specific version thing.

It's not ideal, but at least most of these are only used in the `kernel` crate, i.e. if there's a breaking change to these features it should be fixable without widespread changes.