Comment by mustache_kimono | Hacker News Reader

Comment by mustache_kimono | Hacker News Reader

Parent Full thread

mustache_kimono

> They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses).

My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/

> And the policies around unstable Rust features (at least they are acknowledged as a problem):

I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same.

Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.

IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are still in wide use in the kernel. Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.

You're not wrong, but at this point, there's close communication between the Linux folks are the Rust team, and the Rust team has committed to stabilizing things that the Linux team needs. There is basically no chance that suddenly one of the core things they need is going to disappear. They've already gone through the list and checked that it's all stuff that is eventually going to land.

> Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.

I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making?

Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard.

Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list.

So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.

It still does, no? Linux isn't written in standard C, it's just that clang caught up with gcc in extensions.

Work was done in both directions. Some of the more esoteric things go ripped out while clang added support for what was left.

Reply on news.ycombinator.com