Should the Linux Kernel Accept Drivers Written In Rust? (lwn.net) 169
Packt's recent story about Rust had the headline "Rust is the future of systems programming, C is the new Assembly."
But there was an interesting discussion about the story on LWN.net. One reader suggested letting people write drivers for the Linux kernel in Rust. ("There's a good chance that encouraging people to submit their wacky drivers in Rust would improve the quality of the driver, partly because you can focus attention on the unsafe parts.")
And that comment drew an interesting follow-up:
"I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs."
But there was an interesting discussion about the story on LWN.net. One reader suggested letting people write drivers for the Linux kernel in Rust. ("There's a good chance that encouraging people to submit their wacky drivers in Rust would improve the quality of the driver, partly because you can focus attention on the unsafe parts.")
And that comment drew an interesting follow-up:
"I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs."
No, just no (Score:3, Insightful)
Re: No, just no (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
If one can not write a driver in C,
they should not be near a computer.
I write drivers for a living. It's not hard, but most of them have bugs that are difficult to uncover in testing. The bugs aren't usually significant enough to keep you from getting your computer to work or to get an embedded platform shipped. Usually just horrible security flaws and similar classes of bugs we can ignore for business reasons.
Re: (Score:2)
In practice, very few people can write 100% correct C, even among Linux kernel developers. I think it's time that we accept that fact and deal with it.
Take a random Linux driver and carefully check all of its error handlers. I'd say there is a 50% chance it doesn't respond properly or fails to clean up in at least one of them. And that's probably a conservative estimate. (I have actually found and fixed several bugs in Linux.)
Of course Rust wouldn't be able to catch all of those problems, but cases where fo
Re: (Score:2)
Perhaps one can write a driver in C but doing so in Rust is more efficient for him.
Honestly, if someone has an opinion like yours, he should probably not work in the software industry.
Re: (Score:2)
What you need is to output the intermediate "C" code that the Rust->C translator passes to the "C" compiler, since Rust is not actually a language that compiles to machine code without the aid of a "real" compiler.
Ada (Score:5, Informative)
Re:Ada (Score:4, Insightful)
Someone was working on it... https://github.com/alkhimey/Ad... [github.com]
If people try it with Ada or Rust or whatever and it's shown to be demonstrably better than C for some use case, more power to them.
Re:Ada (Score:4, Informative)
Rust is significantly safer than Ada. For example, Ada doesn't guarantee freedom from use-after-free bugs, but Rust does. (Well, unless you use the latest Ada-SPARK preview, but that's a lot less mature than Rust, and more burdensome.) UAF is a major source of vulnerabilities both in the Linux kernel and in unsafe languages generally.
Re: (Score:2)
Which is hilarious because "use after free" bugs are one, single, kind of error.
It'll stop a buffer from being overrun. It _wont_ stop a routine that assumes "no user id = root permissions". Which shipped in real, production code.
Re:Ada (Score:4, Insightful)
It _wont_ stop a routine that assumes "no user id = root permissions". Which shipped in real, production code.
What a terrible language Rust must be. It only stops most of the security problems in C code, not all of them.
Re: (Score:2)
Re: (Score:2)
I would also like to consider a microkernel approach for Linux to a greater extent for the future which would make the bulk part of drivers located in userspace or in Ring 2 on Intel processors. (this would of course depend more on which processor architecture you work with.)
But for the bread and butter part of the kernel I think that using any compiled language that won't create too much overhead and strain on memory management could work. Maybe Fortran for that part of the driver code could prove interest
Re: (Score:3)
Microkernels are shit. Writing multi-threaded drivers is very difficult, because the separate memory spaces result in decoherence between the threads. Imagine you have a single resource shared by a multi-threaded driver. When one driver thread makes a change to the resource, there is always a delay before this information is distributed to the other drivers, meaning that they will be running with partially outdated information.
The standard solution by microkernel afficionados is to only implement single thr
Re: (Score:2)
That's the price to pay. You can get either high security or high performance, don't expect to get both at the same time. It's all about compromises.
Re: (Score:3)
Ada isn't a zero-cost language. Rust is.
Fuck. No. (Score:3, Informative)
Don't start adding random fucking languages. Port it all together or piss off. Anything else is a maintenance nightmare and very likely doubles the weight of any system software and support infrastructure.
Re:Fuck. No. (Score:4, Informative)
librsvg was recently rewritten in Rust. Did that create a maintenance nightmare and "double the weight of system software and support infrastructure"? No.
Re: (Score:3, Informative)
That port has caused problems [lwn.net] for people on lesser used architectures where Rust is not available. That article was from almost a year ago, and I don't know how the issues was resolved, but it shows that changing the language to a new one can cause unexpected maintenance problems.
Lame power grab. (Score:5, Insightful)
WARNING: Some assholes are being paid to overhype Rust as a lame attempt to make everything dependent on it.
Re: (Score:2)
Who do you think is paying people to overhype Rust?
Re: (Score:2)
Today Rust, tomorrow it's Python that's going to be considered for the kernel and then someone thinks it's a good idea to realize Haskell in the kernel.
Personally I think it could be nice to integrate Fortran in the kernel.
Re: (Score:2)
Personally I think it could be nice to integrate FORTRAN in the kernel.
FORTRAN . . . ? What a puny plan! Some brave, daring and unafraid person should rewrite the Linux kernel in APL!
And extra points for the folks who rewrite it in SNOBOL!
Re: (Score:2)
Considering that I have seen an operating system where parts were written in Cobol nothing is sacred.
Re: (Score:2)
Pretty much. Unfortunately, you cannot make fanatics go away. You can just ignore them and their lies.
Re:Lame power grab. (Score:4, Informative)
I think they hadn't found a way to carpet bomb everything with "what about rust" in a week, so someone submitted a story with rust in it.
At some point this stops being amusing and makes me want to avoid the language. If the people using the language are this annoying, I cannot imagine how annoying the language is.
Re: (Score:2)
WARNING: Some assholes are being paid to overhype Rust as a lame attempt to make everything dependent on it.
There is definitely a lot of book authors going on frequent conference tours trying to build commercial interest in Rust.
The functionality of Rust seems fine to me. It's trying to solve some problems that C doesn't address, so it's worth discussing. I think for a mature software codebase that has thousands of contributors we need to consider carefully about using languages that are likely to get breaking changes in the future like Rust (or C++, haha)
Re: (Score:3)
Why was completely unsubstantiated and transparently absurd charge modded up?
Betteridge is right. (Score:5, Funny)
If you're too incompetent to write quality code in C you're too incompetent to write kernel code.
Re: Betteridge is right. (Score:4, Insightful)
Right, because none of those Linux kernel coders (and patch reviewers) have ever let a bug get to production before. Certainly no security holes or crashing bugs. No siree!
Re: Betteridge is right. (Score:5, Informative)
You've completely missed the point.
To write high quality kernel code you must fully understand what's going on down inside the processor. As soon as you use a language that tries to hide those necessary details you're going to have issues.
Re: Betteridge is right. (Score:4, Insightful)
To write high quality kernel code you must fully understand what's going on down inside the processor.
That's more the compiler or assembly language programmer job. Keep in mind that Linux runs on several types of processors and a kernel developer might not be familiar with all of them.
But you still have a point; you have to understand basic principles on how machines work. An example of this; I often see developers fetching large result sets into memory then, sending it to the browser afterwards at the presentation layer which makes their applications memory pigs. I often instruct them to change it in code reviews and show them how to; basically, pass the database cursor to the presentation layer and have the presentation layer fetch results one at the time and stream them to the browser right away. The memory used by each result is then freed right away. With large result sets, you can reduce the application memory usage by a factor of 1000 or more thus being able to handle many more concurrent requests before the server runs out of memory. It also makes the application much quicker before it begins to send something to the user, enhancing user experience.
Re: (Score:3, Insightful)
If you don't understand pointers or dynamic memory management, Rust is a good language choice because it hides those details.
But if you don't understand those details, you should not be writing kernel code.
When you are writing kernel code, you don't want those details hidden.
Re: (Score:2)
To take this line of reasoning a bit further: When you are writing kernel code, you are actually implementing dynamic memory management. Using a language which abstracts this isn't going to work.
It can't be turtles all the way down.
Re: (Score:3)
You can write a memory allocator in Rust.
https://github.com/redox-os/ra... [github.com]
However Rust code in the Linux kernel can use the existing allocator, and there is no pressing need to rewrite that AFAIK.
Re: Betteridge is right. (Score:5, Informative)
> But if you don't understand those details, you should not be writing kernel code.
That is correct. However, Rust doesn't hide those details. It gives you control over when to dynamically allocate values and when those allocations are freed (e.g. using Box and drop()). You can decide whether you want to use schemes like reference counting (e.g. using Rc or Arc), and if you do, Rust gives you control over when references are acquired or released.
But unlike C and C++, if you make a mistake that leads to a memory safety bug (e.g. use after free), Rust will reject the code.
Re: (Score:2)
You've completely missed the point.
We got your point and it's flat out wrong.
To write high quality kernel code you must fully understand what's going on down inside the processor.
That's not even slightly correct. C is not an especially good representation of what is going on down inside the processor, no more than Rust or C++. All of them share a very similar abstract machine.
As soon as you use a language that tries to hide those necessary details you're going to have issues.
Well then you're screwed. Even
Re: (Score:2)
If that was true you would need to write everything in assembler as C indeed hides the processor completely from you.
Re: (Score:2)
It may be that Rust programmers are also capable of writing bugs. Just a thought.
In which case, yeah, stick to one language in the kernel.
Re: (Score:3)
"No language can ensure perfect code, so they're all the same" is nonsense. Languages like Rust prevent important classes of bugs that are common in C, and that's a real advantage.
Re: (Score:2)
Your statement is clueless. Problematic code is written by problematic coders. Do away with one class of bugs and they will just find other ways to do damage.
Re: Betteridge is right. (Score:5, Insightful)
Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in, it would be stupid to stick to C just because of some principle that says that one must go through a challenge in order to prove oneself worthy.
Re: (Score:2)
C isn't more of a challenge than Rust is.
Though to be fair, it is harder and harder to find good C programmers who aren't creeping up on retirement, especially good C programmers with low level experience (not just some interface glue between components). I don't think that's fixed by having some gung-ho Rust programmers show up and start proselytizing.
Re: Betteridge is right. (Score:4, Insightful)
> C isn't more of a challenge than Rust is.
Writing C code that is completely free of memory safety bugs and other exploitable vulnerabilities is a huge challenge. It's about as hard as always writing code that is perfectly bug-free. Basically no-one can do it at scale.
Writing C code that works most of the time and has lots of vulnerabilities is indeed quite easy, and for a long time that was considered good enough. That needs to change.
Re: (Score:2, Troll)
Bullshit and bullshit. Well, maybe it is this hard for _you_, but for any competent C coder this is most decidedly not true.
Re: Betteridge is right. (Score:4, Interesting)
Are you arguing that it should be kept difficult, because if it was easy then you would not be the only one able to do it any longer?
Re: Betteridge is right. (Score:4, Interesting)
Sorry, but no. Better code isn't the only criterion. It's also got to be portable to a wide variety of platforms.
What they should do is create a Rust to C translation program. That way the "safe Rust code" can be translated into the "portable C code".
Of course, there's also the problem of maintenance. So the code produced by that translator had better be intelligible. (Even some people produce C code that does the job properly, but is totally unintelligible. So this isn't an added requirement.)
Re: (Score:2)
What they should do is create a Rust to C translation program
How is this any different from compiling to LLVM?
Re: (Score:2)
Good C code is directly intelligible to a large number of programmers, and it runs on a lot of computers that LLVM code doesn't run on.
Re: (Score:3)
The Kernel Needs A Protective Order (Score:2)
The kernel devs need a protective order to keep dimwitted little shits like this away.
These idiotic hipsters fanboys will sit in dev or other forums spamming their calls to use whatever shit tech they have latched onto relentlessly.
But why...
But why...
But why...
This is exactly how the systemd fiasco was able to rammed down the Linux world's throats.
Re: (Score:2)
Could not agree more.
Re: (Score:3, Interesting)
Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in, it would be stupid to stick to C just because of some principle that says that one must go through a challenge in order to prove oneself worthy.
Honest question here: wouldn't you have to carry the RUST runtime libs inside the kernel? Or have every driver include its own RUST runtime? KInd of a la docker or what not?
https://stackoverflow.com/ques... [stackoverflow.com]
What would be the impact on the kernel? What should we do when the next language comes up? Add its runtime to the kernel too?
Re: Betteridge is right. (Score:2)
Re: (Score:2)
The honest answer to your question is yes.
Well then, Rust isn't going to be a good fit. Because even C needs to include kernel specific structures and libraries to build kernel components. Basically, a subset of (and different from) the stdlib stuff that userland apps need. I haven't seen any reasonable proposals to build this infrastructure for Rust.
Re: Betteridge is right. (Score:5, Informative)
Unlike most programming languages, but like C, the Rust standard library is optional. You can write Rust programs that don't use it, and people do.
https://rust-embedded.github.i... [github.io]
For example people are writing bootloaders in Rust.
https://github.com/rust-osdev/... [github.com]
The people actually working on writing Rust code for the kernel are implement Rust interfaces to the existing kernel libraries.
Not at all what it's about (Score:2)
I'm not sure which you are suggesting / confused about.
Are you thinking it would be a good idea for the kernel to be a mishmash of various languages, with assorted programming paradigms and different ways of doing things?
Alternatively, is it unclear what the purpose of a kernel is?
The kernel, of course, does things like translating the logical memory addresses used by userland software into actual physical addresses, controlling which programs can access which portions of memory - including memory locations
Re: (Score:2)
Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in
That's a woefully incomplete argument. It depends entirely on what you're trying to do with a language, and the lower the level you're working on the less abstract something should be. Rust is safe because it abstracts away and manages many of the things which make C flexible and predictable, not exactly the kind of language you want on the lowest level of the OS just because it is just as fast.
Re: (Score:3)
Don't you ever wonder why they drive automatic?
Re: Betteridge is right. (Score:4, Insightful)
"Extend this inane thought process to the logical extreme. "
There is nothing logical about that extreme.
In your extremist world you'd still be rejecting the idea of drivers entirely, as they just coddle programmers. Whose going to be able to write code that interfaces to hardware if application programmers start relying on device drivers to hide all the complexity of supporting disk controllers, video chip sets, networks, and printers...
Nobody will be able to write device drivers at all as the necessary basic competence will be gone...
Right?
"Who can write such a language or indeed even safely maintain it if you've succeeded in drumming the concept of basic competence out of an entire generation of programmers?"
If only we had some way of creating projects where complexity could be organized and broken up.
I mean you do realize that it is already the case that the guy who works on languages is already not the guy writing device drivers. And the guy writing print layout and typesetting software isn't usually the same guy writing printer device drivers. (and its not because he isn't "competent".)
Re: (Score:2)
Re: (Score:2)
I do write code that is solid and very security critical in C. It also has high, not negotiable performance requirements and must have both a custom memory management and a low memory footprint. Come to think of it, the Linux kernel would also have pretty much these requirements.
If you are incompetent enough to call any engineer doing something you cannot do and you do not really understand "incompetent", then the problem is most definitely on your side.
Maybe in the future, not now. (Score:2)
Rust is still not compatible itself, it's constantly changing. Wait for the ABIs and the standard to stablize, afterwards, if Rust becomes as popular as C, sure, why not.
Or maybe not (Score:3)
Ok, I just read the comment by the guy who said that if Rust should be let in, so does Ada. His point is valid, no reason to make Rust special just because of the stupid hype around it.
Re: (Score:2)
Add Fortran and Cobol to the list to add to the kernel too then.
Re: (Score:2)
I don't think Cobol is low level enough, maybe Fortran is.
Re: (Score:2)
I have encountered a system where part of it was written in Cobol so it's possible even though I wouldn't recommend it due to all the headache you get on the side.
Still no m68k support (Score:3)
That and wait for Rust to support a code generator other than LLVM. There are still a lot of architectures on which Linux runs that LLVM does not target, such as m68k. Apparently LLVM drivers don't want to merge patches to add m68k experimentally [llvm.org] because there are already so many experimental back ends in LLVM that they may impose an undue maintenance burden on other maintainers [llvm.org].
Re: (Score:3, Insightful)
Rust doesn't need a stable ABI to be useful in the kernel. The kernel itself doesn't have a stable internal ABI.
Nope! (Score:4, Insightful)
That won't happen (Score:2, Interesting)
Rust by design won't let you talk directly to hardware. That by itself means you will never get true kernel components in Rust. You'd have to write a barebones module in C that then passes messages to Rust, you've now created basically a userland driver a la FUSE and the whole point of safety within Rust is moot.
The same thing happened to Python and Java. Super-safe languages, type safety, VM's, safe memory/pointer/heap/stack management but anything relevant, anything interfacing hardware, anything that req
Re: (Score:2)
The same thing happened to Python and Java. Super-safe languages, type safety, VM's, safe memory/pointer/heap/stack management but anything relevant, anything interfacing hardware, anything that requires performance has to be written in (unsafe) C/C++ making the entire language safety features largely moot.
Exactly, we have seen this before, there's nothing new here. Leave the kernel alone. Let it do one simple thing and not crowd it with many functionalities in a Jack of all trades scenario :)
Re: (Score:2)
Um, I'm not saying that more languages should necessarily be thrown in, but the Linux kernel on my machine is like 9MB. Compressed. Plus modules.
It would be nice to have a simple kernel that does one thing, but Linux would not be that kernel...
Re: (Score:2)
Python is very nice glue code for C modules though!
Re: (Score:2)
It is REALLY hard to keep track of what the fuck is going on in a lazy functional program.
I started writing Haskell a while ago. I am in love with the type system, but the laziness makes it almost impossible to be sure you know how your program is going to perform or how much memory it will use. It's super easy to make counterintuitive mistakes. And there are a bunch of lazy idioms baked into the way things are done in Haskell, as well as the language itself, so you can't just force everything into a super
Absolutely not (Score:3)
"Safe" languages add too much overhead for the compiled code to be an accurate reflection of what the programmer wrote. As for claims that "C is the new Assembler", that one is bogus - C has always been considered to be "portable Assembler" depending on which features are used.
Re: (Score:2)
Re: (Score:2)
I once used Ada to write the operating system and about a dozen drivers for a complex embedded system. It was a requirement. I told many afterwards that during those few years of programming at the device level in Ada, I had spent more time debugging at the assembly code level than when I wrote in any other language including assembly. The reason that happened is exactly as you indicate - the compiled code included a lot of unexpected hits that you just can't tolerate at the device programming level.
Re: (Score:2)
Rust doesn't add much overhead to the compiled code. The safety happens during compilation, not at runtime. In many cases it's faster than C because the constraints allow the compiler to optimize in ways a C compiler can't.
I'm not a Rust fanatic. I've just looked into it to see what the fuss was about. You should too. Even if you don't like it, it's good to understand what another language does well.
Re: (Score:2)
I'm not a Rust fanatic. I've just looked into it to see what the fuss was about. You should too. Even if you don't like it, it's good to understand what another language does well.
It is just one more "Silver Bullet" language that is unlikely to pan out. I have seen quite a few of those. No reason to believe this one is different.
Sure (Score:2)
I'm working on some new drivers written in LISP.
Re: (Score:2)
You gave me dandruff right now.
You're all missing the point... (Score:5, Funny)
Re: You're all missing the point... (Score:2)
Re: (Score:2)
How can you do that? Is not the very idea of a "driver" that of a "slave driver", i.e. something that orders the hardware around? I think we need to get rid of drivers in the kernel! They are not a solution, they are a problem!
It'll break laptop kernels (Score:2)
Because rust never sleeps.
Re: (Score:2)
My My... Hey Hey...
Nope (Score:2)
Re: (Score:2)
Well, how about FPGA programming?
No! (Score:2)
an important aspect of security is impacted (Score:2)
One of the more important and famously touted aspects of open source security that Linux benefits from is the number of eyes reviewing the code. It both makes it harder to plant intentional flaws and less likely for accidental ones to reach release.
At least in initial deployment, wouldn't this benefit be reduced for Rust code? What percentage of the kernel developers are experts in Rust? What happens when a C developer in one area of the kernel has to debug a problem in which their code is interacting badly
Re: (Score:2)
That's why any other language in C should only be considered for userspace or Ring 2 drivers, then the other language module would be isolated.
Absolutely, and also in C++ (Score:2)
Absolutely. Linux kernel should be coded using the best tool for the job. Which stopped being plain old C more than a decade ago. Linus's protestations notwithstanding. Linus's arguments are purely bogus, withstanding no real scrutiny, and only succeed on the strength of his personality and position, not logic. In other words, Linus is just being a dumb git about this. Again.
no is the answer to retorical headlines (Score:2)
Just remember: https://en.wikipedia.org/wiki/... [wikipedia.org]
And I like all the comment in the lwn article from peole that registered to lwn just to say "I love to help" even if they often don't know anything about kernel programming ...
It looks like the people want it just to increase the visibility of rust, but they don't really care about linux.
The majority of negative commenters have no idea (Score:2)
Not possible (Score:3)
The linux kernel is currently about 25M lines of code, 2.5M of which are in arch (i.e. very low level code with inline assembly that is not currently supported officially by rust). Mixing language is not a sane option for any project of this size and rewriting the entire thing would cost billions of dollars.
So the answer is simply no.
Next (stupid) question (about rust)!
Re: (Score:2)
This. Thank you for the most sane response in this thread.
No... the Linux kernel should get rid drivers (Score:2)
It's about damn time the Linux kernel was... JUST THE FRIGGING KERNEL and if we're never going to have a standard ABI, there should at the very least be a way to match versions to versions. So, when you open "make menuconfig" for example, it should make use of a repository listing (apt, npm, etc... style) and download a catalog of modules compatible with the given kernel version and when the build starts,
Note to self (Score:2)