Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel (phoronix.com) 79
Phoronix reports:
As mentioned back in July, upstream Linux developers have been working to figure out a path for adding Rust code to the Linux kernel. That topic is now being further explored at this week's virtual Linux Plumbers Conference...
To be clear though, these Rust Linux kernel plans do not involve rewriting large parts of the kernel in Rust (at least for the foreseeable future...), there would be caveats on the extent to which Rust code could be used and what functionality, and the Rust support would be optional when building the Linux kernel. C would remain the dominant language of the kernel and then it's just a matter of what new functionality gets added around Rust if concerned by memory safety, concurrency, and other areas where Rust is popular with developers. Various upstream developers have been interested in Rust for those language benefits around memory safety and security as well as its syntax being close to C. There would be a to-be-determined subset of Rust to be supported by the Linux kernel.... While the Rust code would be optional, the developers do acknowledge there are limitations on where Rust is supported due to the LLVM compiler back-ends. But at least for x86/x86_64, ARM/ARM64, POWER, and other prominent targets there is support along with the likes of RISC-V.
Nothing firm has been determined yet but it's a topic that is still being discussed at the virtual LPC this week and surely over the weeks/months ahead on the kernel mailing list. There is Rust-For-Linux on GitHub with a prototype kernel module implementation. There is also the PDF slides from Thursday's talk on the matter.
It's not clear to me that this is a done deal. But the article argues that "it's still looking like it will happen, it's just a matter of when the initial infrastructure will be in place and how slowly the rollout will be..."
To be clear though, these Rust Linux kernel plans do not involve rewriting large parts of the kernel in Rust (at least for the foreseeable future...), there would be caveats on the extent to which Rust code could be used and what functionality, and the Rust support would be optional when building the Linux kernel. C would remain the dominant language of the kernel and then it's just a matter of what new functionality gets added around Rust if concerned by memory safety, concurrency, and other areas where Rust is popular with developers. Various upstream developers have been interested in Rust for those language benefits around memory safety and security as well as its syntax being close to C. There would be a to-be-determined subset of Rust to be supported by the Linux kernel.... While the Rust code would be optional, the developers do acknowledge there are limitations on where Rust is supported due to the LLVM compiler back-ends. But at least for x86/x86_64, ARM/ARM64, POWER, and other prominent targets there is support along with the likes of RISC-V.
Nothing firm has been determined yet but it's a topic that is still being discussed at the virtual LPC this week and surely over the weeks/months ahead on the kernel mailing list. There is Rust-For-Linux on GitHub with a prototype kernel module implementation. There is also the PDF slides from Thursday's talk on the matter.
It's not clear to me that this is a done deal. But the article argues that "it's still looking like it will happen, it's just a matter of when the initial infrastructure will be in place and how slowly the rollout will be..."
Re: (Score:1, Funny)
Re: Communist SJWs (Score:2)
Now we know... (Score:2, Insightful)
Re: (Score:2, Offtopic)
Not to mention that their CoC makes commenting on someone's 'skill' and offence. The majority of comments I've seen about the plus's of rust are 'the compiler and the tool chain handle 'that''
The Golden Question (Score:2, Interesting)
Q: Is REALLY so EASY to write a kernel that they can spend SO MANY time looking for a way to make it FUC***G complex, forcing the developers to:
a) Use multiple debuggers (C debugger, C++ debugger, Rust debugger, etc.)
b) having to know different programming languages
etc.?
The Golden Question, Number 2 (Score:5, Insightful)
Is the purpose of adding Rust to get more money for supporting Linux?
Lennart Poettering, who works for Red Hat [wikipedia.org], introduced SystemD. Possibly a badly-designed user interface is a method Red Hat uses to make more money. People pay Red Hat to get technical guidance.
Systemd Named 'Lamest Vendor' At Pwnie Security Awards [slashdot.org]. (July 29, 2017)
Lennart Poettering: Open Source Community "Quite a Sick Place To Be In" [slashdot.org] (Oct. 6, 2014)
Choosing the name RUST for a computer language shows a lack of social ability.
RUST - Makes iron into useless red dust.
RUST - Ridiculously Unpleasant System Tweak?
They should have used Iron (Score:2)
Then Rust comes by itself.
[Sigh] (Score:2)
Another bullshit toolchain I'll have to install for only one purpose (building the kernel). And then it sits, unmaintained for months or years until I've got to build it again.
Any chance that we can get a Rust to C translator built?
Re: (Score:3, Insightful)
The problem will rear its ugly head in about 2 years when Rust has changed so much, it won't be able to compile the old code, the problem will be who will maintain all that code every year as features and requirements in Rust change seemingly every day.
Re: (Score:2)
Rust never sleeps.
Re: (Score:2)
That's why the process suspension code will remain in C.
i love rust however (Score:5, Interesting)
i have many questions regaring making the linux kernel wholly dependent on LLVM (since that is what would happen if you had Rust inside of it)
in order to compile the kernel you traditionally only needed to get the gcc toolchain working.
if you add rust, then you will need to compile llvm and its attendant toolchain, and then rust as well. and will you also need cargo? (rusts package manager... so much of rust is in packages that its kind of required even to do a lot of basic stuff). now, i will admit that building llvm / rust is relatively easy on mainstream platforms, but i wonder if it is as easy on weird platforms?
i am not sure how this would impact people trying to do experiments or weird ports with the linux kernel.
i also wonder how this would affect people trying to cross compile the kernel. it seems to me like llvm and gcc would both have to support the target you are going to build for, whereas before you only needed gcc to support the target.
Re: (Score:2)
This is the biggest problem I think.
Re: (Score:2, Informative)
Back in the 90's we had to compile GCC three times and then build the kernel, sometimes fixing type bugs along the way. It was a solid day's work, maybe letting the compiles run overnight.
There doesn't seem to be much with this proposal that can't be scripted. For truly new ISA's, adding an LLVM backend is actually easier than GCC.
Re:i love rust however (Score:5, Insightful)
My concern is more to do with having LLVM be a mandatory requirement to build the kernel. At the moment you at least have a choice of GCC or LLVM.
LLVM is Apache License with various LLVM specific exceptions. GCC is full GPL v3 with the runtime library exception. It might seem like a trivial distinction to some but it's actually very important that Linux can always be built with a GPL licensed compiler suite.
LLVM: "the problem has always been code ownership" (Score:2)
For truly new ISA's, adding an LLVM backend is actually easier than GCC.
Getting the backend accepted upstream is a different story though. LLVM rejected a patch to add an m68k (Motorola 68000 family) backend because no one stepped up to maintain it for the next ten years. From a post to the mailing list by Simon Pilgrim in May 2019 [llvm.org]:
Re: (Score:2)
does freebsd use rust in kernel? (Score:1)
if bsd 'goes there' then i will feel alot more comfortable with it happening in linux
Re: (Score:1)
i have many questions regaring making the linux kernel wholly dependent on LLVM (since that is what would happen if you had Rust inside of it)
LLVM is the future. GCC itself limited its future by insisting that it could not be allowed to be extended easily via plugins or access to intermediate code or libraries. Those choices certainly won some of the philosophical battles, but they may have lost the long term war. GCC is certainly not dead, and it will continue, but the real money is currently being directed towards LLVM, and in the end, money (and therefore developer resources) matter.
Re: (Score:3, Interesting)
LLVM is not easy to get working on "weird" platforms. Further, to get patches upstreamed for these platforms, one must provided a dedicated server for their testing needs. So you have server cost + any issues they have with your patches. It's not pleasant.
As for rust, since it depends on LLVM you have double the hoops to go through. The source includes a modified version of LLVM. If it doesn't have upstream patches for your OS, you get to port LLVM a second time, then rust and keep doing it with each new
Re: (Score:2)
It is possible to compile the entire kernel in LLVM:
https://www.kernel.org/doc/htm... [kernel.org]
But that of course many obscure platforms only supported by gcc but not supported on llvm.
Given it is unlikely Rust will be rewritten in gcc, nor Linux would drop many smaller platforms, I am not sure how this will work.
If the rust people want (Score:4, Insightful)
Re:If the rust people want (Score:5, Funny)
Looks like Linux is in decline (Score:5, Insightful)
When a crappy, unfinished language with grande claims and shaky support gets seriously considered for use, then sanity has left the building.
Re: (Score:3)
I wish i could mod this comment up...
From what i see on the outside in, but a linux user for many years, it's a fad language. Like java and dozens of others.
Re: (Score:1)
A bit of a stretch to call Java a fad, after 22 years. I'm sure you could have come up with a better example. Python, maybe?
Re:Looks like Linux is in decline (Score:5, Insightful)
-Is it worse to be off-by-one or off-by-unkown?
Re: (Score:2)
Rust sounds like a haven for lazy and sloppy coders. 'Let the compiler clean up my mess'. Restrict this to optional drivers and modules. Linux proper should never require this.
Indeed. Incompetents finally hoping to create good code without having to fix their incompetence. Of course, that cannot work.
Re: (Score:2)
> Incompetents finally hoping to create good code without having to fix their incompetence.
Are you calling the linux devs who have let exploits slip past them "incompetents"?
Because that'd be most of the names you know.
Re:Looks like Linux is in decline (Score:4, Insightful)
> Incompetents finally hoping to create good code without having to fix their incompetence.
Are you calling the linux devs who have let exploits slip past them "incompetents"?
Because that'd be most of the names you know.
Commend made in bad faith is comment made in bad faith. Alternatively, maybe you are one of the incompetents? Because nobody competent would ever believe that "incompetent" refers to "have let a relatively low number of bugs slipped past or made a relatively low number of mistakes". Quite obviously. Everybody makes mistakes. The difference is in the frequency and the quality of the mistakes.
Re: (Score:2)
Errare humanum est. It seems the fad of Rust is the ability to quickly produce code that by language design has restricted the frequency and quality of errors. Obviously making something foolproof we can expect to introduce a better fool.
Re: (Score:2)
Indeed. Also, Rust can do nothing about logic errors, bad design, lack of understanding how a technology works, etc. And these are the real killers, because there often is no simple fix. For example, the classical buffer overflow and friends is easy to find and easy to avoid, no Rust required for that, just competent testing and coding. In fact, the very fact that they are easy to find is what makes them dangerous. Fro race conditions, somebody that cannot competently avoid races is likely to cause lockups,
Re: (Score:2)
Re: (Score:1)
Do you really think that you can't compile in exploits in Rust? https://medium.com/@shnatsel/h... [medium.com]
Re:Looks like Linux is in decline (Score:5, Informative)
Restrict this to optional drivers and modules.
Based on comments made earlier by Linus, he seems to agree with you.
Re: (Score:2)
When you say "sounds like" it suggests you have never actually learned or used Rust. It's nothing like what you describe.
Re: (Score:2)
Re: (Score:2)
Thanks. I do appreciate the sentiment.
Re: (Score:2)
Re: (Score:2)
If that happens, then fork the Kernel without Rust. It's open source and free as beer. :P
Re: (Score:2)
Free beer? Where?!
Conspiracy theory... (Score:2)
Stainless steel doesn't rust (Score:5, Insightful)
Re:Stainless steel doesn't rust (Score:4, Informative)
Indeed. Very much this. "If it is not broken, do not fix it" is one of the very base rules of all good engineering. Developers from the "young, dynamic, clueless" camp violate this time and again, to the detriment of everybody. The kernel is not broken and neither is its development approach. These people need to stay the hell away from it!
Re: Stainless steel doesn't rust (Score:1)
My informed opinion: shit needs to work. If the cost of that is that it's hard to learn, then so be it. It's hard to learn because it's innately complex, not because the tools or the language suck or because toxic masculinity, systemic racism, buried Jew gold, the ill
Re: (Score:2)
Very much so. Writing kernel code is not hard because Linux does it in C. Writing kernel code is hard because kernel code is hard. Anybody that needs a language that holds their hand is bound to fail even with that hand-holding.
Re: (Score:2)
In my professional experien
Re:Stainless steel doesn't rust (Score:5, Insightful)
Totally agree, if they can't figure out memory safety in C, then they shouldn't be touching kernel code. C is about as straightforward as it gets wrt memory safety. There are no classes to hide allocations and create hard to trace leaks. There's basically malloc / free and alloca. So long as your code isn't peppered in casts, in which case put down the compiler now, it's not that hard. Know what a pointer is (reference / dereference), limit casting, be careful with string termination, and the rest should be easy.
Re: (Score:1)
And should real programmers turn off all compiler warnings too? After all, for a careful programmer they're unnecessary also. Have no memory safety bugs made it into the kernel recently? Rust may or may not be the solution, but denying there is an issue isn't the solution either.
Re: (Score:1)
Re: (Score:2)
But stainless does rust. It's only less reactive than non-stainless.
Why yes, I am fun at parties.
Rust in the kernel is a bad idea, though. Jokes aside, even if it's used only for optional components it's still going to increase requirements for many users.
Re: (Score:1)
Let's be honest ... (Score:1)
It's a slippery slope. Either you like it, or you don't.
The question is if said liking correlates with it actually being good for everyone (or even anyone) affected by it.
Or if it is just a fashion or a cult.
I can't judge that yet, and neither can probably the vast majority of people that are arguing about it. ... as I said ... I can't judge that *yet*. I'm
I like the parts of Rust. But dislike others. Mainly because it feels half-assed and far from perfect due to C cultism and thinking inside the C box. But
Rust is a viral infection (Score:2)
Rust is based entirely upon RAII which cannot directly coexist with non-RAII code without wrapping everything it touches in an RAII interface.
Memory related programming errors can be largely mitigated by imposition of constraints and static analysis. It is not necessary to invent a new language or impose RAII.
Re:Rust is a viral infection (Score:4, Insightful)
Why aren't they largely mitigated then?
Re: (Score:2)
Laziness? Lack of resources?
Re: (Score:1)
They are. Do you see that many problems in the Linux kernel? There will always be exploits and vulnerabilities, even Rust has had them, in their standard library nonetheless. You can never get completely secure, you can only get a false sense of security.
I would rather prefer SPARK (with Ravenscar) (Score:2)
Linux kernel also hooking up with strangers (Score:1)
Ready for any experiments!
SystemD to the rescue (Score:2, Funny)
It's so obvious that SystemD is the preferred solution.
RUST? (Score:1)
Might as well add GW-Basic and Turbo-Pascal into the mix. I mean, the goal of adding RUST to Linux is to fuck things up, isn't it?
Awesome! (Score:3)
This opens the door for getting my Javascript process scheduler into the kernel!