Linus Torvalds: Rust Will Go Into Linux 6.1 (zdnet.com) 26
slack_justyb writes: As previously indicated on Slashdot, Rust was slated to be coming to the Linux Kernel sometime in the 6.x version. Well wonder no longer on which version of kernel 6.x will have the first bits of Rust officially in the kernel, as Linus has confirmed that 6.1 will be the first with the new NVMe kernel drivers being in Rust. The first version non-production ready code for the NVMe Rust based kernel drivers were already producing performance comparable to C code. So the final drivers to hit 6.1 are already looking promising. It also helped Rust's case that, thanks to the ground-breaking work of Linux kernel and Rust developer Miguel Ojeda, Rust on Linux has gotten much more mature. Kernel maintainers were convinced it is time to move forward with Rust in Linux. In short, they agreed that Rust on Linux was ready for work.
Re: Good (Score:2)
It's your choice of either MIT or Apache license. That means it's even more permissive than the GPL license that Linux uses.
Licensing issues? (Score:1, Troll)
The whole kernel is supposed to be GPLv2/3. Rust and its execution binaries are MIT/Apache licensed. To do what Rust does (bound checking etc), it must include a ton of its own code into the compiled binaries. Basically it would be similar to requiring a JVM in every Linux kernel, not sure if everyone agrees with that.
Re: (Score:3)
How is that a licensing issue? You can add permissively-licensed free code to a GPL project and release the whole thing under GPL.
Re: Licensing issues? (Score:2)
But this means portions of the kernel and derivatives are now under a less restrictive license. I always thought you could do this, but only if you are the author and then you implicitly agree the code would fall under GPL and it is only applies for GPLv3 (Linux kernel is v2). Basically either the Rust binaries or even source code (the VM portions) are now GPLv2?
Re: (Score:2)
Only the Linux code written in Rust is GPL2. Rust and it's libraries itself are still Apache/MIT.
Re: (Score:1)
Are you sure this is true? I thought all the bound checking and ownership tracking and such was at compile time and the produced code was basically c
Re:Licensing issues? (Score:4, Interesting)
Rust doesn't require a runtime in the same sense as Java - more like the C or C++ standard libraries. And it doesn't matter what the tools are licensed as. What matters is what license the code written in the language uses, which would be GPL, of course, like the other code in the kernel. A quick search shows that this issue has been considered, and there's apparently no problem with it.
https://www.apache.org/license... [apache.org]
Re:Licensing issues? (Score:5, Insightful)
To do what Rust does (bound checking etc), it must include a ton of its own code
The memory footprint for bounds-checking is very small.
Rust does not bounds-check "unsafe" code (e.g.: memory mapped I/O), and does not bounds-check code if the compiler can determine it is unnecessary. So it is only needed if you are writing "safe" code that is so unclear that the bounds can't be determined. If that is happening, you should learn to write better code.
Basically it would be similar to requiring a JVM in every Linux kernel
That is a silly exaggeration.
Re: (Score:2)
Bounds checking is not the result of bad code authoring, that's just grandstanding. Look who the source is...
Re: (Score:2)
This can happen for a great deal of non-trivial code that works with data not known at compile time
Can you give an example?
When a kernel receives an IP packet, the buffer size is in the packet. So you need to allocate an array of that variable size. But the compiler can "see" that and "know" that the code to process the data doesn't step outside the array bounds. If you haven't used the Rust compiler, you might be surprised at how much it figures out at compile time.
You can set the compiler flags to warn you when the compiler thinks bounds-checking is necessary. You can then look at the code, and 99% o
Re: (Score:2)
Surely a rust-compiled binary or object code is not under any license dictated by rust,. I know of no compiler in popular use that places any limitation on the license of the compiled output of the compiler, even though the binary contains code emitted by the compiler. Runtime libraries do have licensing of course, (glibc being lgpl), which does matter. But it's not clear to me that kernel rust uses anything from the runtime library.
If it's not possible to use rust to make a wholly proprietary executable
Re: Licensing issues? (Score:2)
To do what Rust does (bound checking etc), it must include a ton of its own code into the compiled binaries
Bounds checking is done by individual functions. Rust doesn't use a runtime to enforce that. In fact, if it's compiled the kernel, then it almost certainly isn't using any runtime at all. Basically the same way C works.
I swear, slashdot comments are easily the biggest source of misinformation about Rust.
Let's see how it goes (Score:5, Insightful)
The referenced article states "the debate is over". That is obviously far from the truth. What happens here is that Linux gives the Rust people enough rope to hang themselves. Whether they do or not will be interesting to see and is impossible to predict at this time. Rust has some major issues it needs to overcome in order to actually stay in the kernel. If there is general consent in a year or so that this was a successful move, I will give Rust a chance. Before, not so much. Of course, this can fail in more subtle ways. For example the language can effectively fork into a Linux kernel version and a general use version. Or the Rust code in the kernel has to be written a lot different from regular Rust code. Or bit-rot is observed in the Rust kernel code. Any of that would mean it is still not ready for general use.
Re: (Score:2)
Rust has some major issues it needs to overcome in order to actually stay in the kernel
For curiosity's sake, what issues do you refer to? Besides the maintenance related conjectures.
Re: (Score:2)
Rust probably will be all right, but Rust in the kernel will most likely stay stuck in this version while the outside world moves on.
Re: (Score:2)
It indeed does make sense to incrementally try Rust in the higher-level features and libraries, and only add it to the lowest levels when it proves itself in higher levels over time.
Re: (Score:2)
Indeed. Maintaining software is always harder and more effort than writing it in the first place. Has been known for a long, long time, but apparently only to people with a clue. A cost/effort number I learned in software engineering at University about 35 years ago was 25% for coding and releasing the first release and 75% for maintenance (ignoring planing, specification, etc., but not testing). These numbers seem to be essentially unchanged today.
Rust probably will be all right, but Rust in the kernel will most likely stay stuck in this version while the outside world moves on.
Quite possibly. Rust does not have the maturity for this mo
Making Popcorn Now (Score:2)
Hooo boy this comment section is gonna be fun.
Why not prevent it? (Score:2)
Once rust gets started, it can be difficult to stop, with all the scaping and sanding and polishing, then putting on a protectant. If Linus knowns rust will get in, why not stop it before it happens? Wouldn't stainless steel be a good choice to prevent rust from gettingin?
*whisper* *whisper* *whisper*
Never mind [youtube.com]
I don't want "comparable" (Score:2)
If I am to choose between a decades-old but stable code and a "comparable" but completely new driver, then I will always choose the former. In order to change my mind the new driver would need to have at least the same level of functionality, security, testing and compatibility with both old and new devices, across all manufacturers as the old one. Can the new driver written in Rust do that?
Re:I don't want "comparable" (esp for speed) (Score:1)
Re: (Score:1)
Your rant is stale. Tons of people here have now been using Linux on the desktop for over 20 years. Some of the distros are actually easier to install and use than Windows now, at least for the basic tasks of web browsing for the explicit purpose of Facebook and Youtube. If you figured out all on your own how to post here anonymously in the first place, you definitely could figure out how to do it from Linux, and that is utterly apparent to all onlookers. Really, this complaint is so braindead it just makes