> 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.
Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.
> Sometimes it's nice to know that something will run and compile reliably far into the future.
I'm not sure why you think this is a problem that Rust has? Perhaps you mean something different but the Rust project compiles available code on crate.io upon the release of a new version.[0] C compilers may imagine their new compiler code doesn't break old software, but Rust takes that extra step, so we know it won't.
Now, the Rust kernel is currently using beta and nightly features which are on track for inclusion in the stable Rust compiler. So, yes, right now compilation is tied to a specific kernel version, and may need to be updated if a feature changes. However, any C compiler used to compile the Linux kernel uses non-standard GCC extensions only recently adopted by clang. Imagine if the C standards committee chose to change the syntax/sematics of a non-standard extension. Do you not imagine the non-standard extension would also be similarly deprecated?
The issue seems to be Rust is telling you what is non-standard, and you're yelling "Look it's non-standard!". But consider that the kernel in practice is using lots of non-standard features, and should the C standard simply adopt this non-standard behavior that means likely having to changes lots of code.
I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.
That's how it feels to me. There are crucial issues, namely that there is no spec and there is only one implementation. I don't know why Linus is ok with this. I'd be fine with it if those issues were resolved, but they aren't.
> There are crucial issues, namely that there is no spec and there is only one implementation. I don't know why Linus is ok with this.
I can try to provide a (weak) steelman argument:
Strictly speaking, neither the lack of a spec nor a single implementation have been blockers for Linux's use of stuff, either now or in the past. Non-standard GCC extensions and flags aren't exactly rare in the kernel, and Linus has been perfectly fine with the single non-standard implementation of those. Linus has also stated in the past (paraphrasing) that what works in practice is more important than what standards dictate [0]. Perhaps Linus feels that what Rust does in practice is good enough, especially given its (currently) limited role in the kernel.
Granted, not having a spec for individual flags/features is not equivalent to not having a spec for the language, so it's not the strongest argument as I said. I do think there's a point nestled in there though - perhaps what happens on the ground is the most important factor. It probably helps that there is work being done on both the spec and multiple implementation fronts.
reply