Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux

Linus Torvalds: Rust Will Go Into Linux 6.1 (zdnet.com) 124

Posted by msmash from the up-next dept.
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.
This discussion has been archived. No new comments can be posted.

Linus Torvalds: Rust Will Go Into Linux 6.1 More

Linus Torvalds: Rust Will Go Into Linux 6.1

Comments Filter:

  • Licensing issues? (Score:2, Interesting)

    by guruevi ( 827432 )

    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:Licensing issues? (Score:4, Informative)

      by Mononymous ( 6156676 ) on Monday September 19, 2022 @05:58PM (#62896377)

      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, Interesting)

        by guruevi ( 827432 )

        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?

        • Only the Linux code written in Rust is GPL2. Rust and it's libraries itself are still Apache/MIT.

        • Rust doesn't have a VM.

        • Re: Licensing issues? (Score:5, Informative)

          by exomondo ( 1725132 ) on Monday September 19, 2022 @10:38PM (#62896935)

          But this means portions of the kernel and derivatives are now under a less restrictive license.

          No it doesn't. You can place more restrictions on a permissive license, that's why it is permissive. You can create a restrictive Free Software derivative if you want to, you can even create a proprietary derivative if you want to. The kernel already includes code under permissive licenses, for example [github.com].

          Basically either the Rust binaries or even source code (the VM portions) are now GPLv2?

          You can distribute them under any license you wish so long as you don't violate the terms of the one on which your derivative is based.

        • That's not how GPLv2 works. Just because something is shipped along some GPL2 code does not make that which is shipped along GPL2 as well. If that was the case, no GPL2 software could ever be shipped with any other software in any way, or the whole lot would turn into GPL2. And that does not happen. It's not how it works.

          In this case, all that is required for the sum of the kernel binary is that all code is shipped along and is available. That code may then be dual licensed, and any of the licenses used for

    • 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

      • GP is an idiot. Bounds checking is compiled into it, though all bounds checks that can't be optimized out by the compiler will happen at runtime. The exact same thing is true of C, though C requires you to manually perform bounds checking, whereas in rust, bounds checks are implicit in the struct methods. In the rust standard library, every function that has a bounds check has a matching unchecked version if you really need it, but unless you really know what you're doing, you don't need it. Even if you do

      • Re: (Score:2)

        by ls671 ( 1122017 )

        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

        User input. You can't check user input at compile time because user hasn't done any input yet. So, you obviously need to check it at run time.

    • Re:Licensing issues? (Score:5, Informative)

      by Dutch Gun ( 899105 ) on Monday September 19, 2022 @06:14PM (#62896435)

      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: (Score:2)

        by AmiMoJo ( 196126 )

        The licence of the tools does matter, because unless they are truly free you can't build the kernel without agreeing to onerous terms. Could also be an issue with things like porting, if parts of the toolchain need to be ported as well.

        • When I said "the licensing of tools don't matter", I should probably clarify. I was talking about the flavor of GPL-compatible open source licenses. That is, the original question was whether Apache-licensed tools are compatible with the GPL kernel. Obviously, the same thing can't be said if you required a proprietary, closed source tool to build the kernel. We were talking about other open source tools, not proprietary ones, so I kind of assumed proprietary tools were not even being considered in this

        • The licenses of the tools do not matter at all. The developer decides under which license his code is distributed.

      • 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.

        Interesting, so it doesn't matter what the licensing is on glibc, you can always use it under ANY circumstances? How about Bitkeeper?

        I find your ideas intriguing and wish to subscribe to your newsletter.

    • Re:Licensing issues? (Score:5, Insightful)

      by ShanghaiBill ( 739463 ) on Monday September 19, 2022 @06:17PM (#62896445)

      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.

      • 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.
        That is nonsense.


              a[i] = 5;

        Without bounds checking you do not know if "i" refers to a valid index in the array a. Hs nothing to do with "quality of your code".

    • Re: (Score:2)

      by caseih ( 160668 )

      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

      • But Rust is not a C compiler, it is a compiler that also wraps the code in a layer of safety checks.

        C compiles cleanly to predictable ASM, everything you write in C you can manually translate to machine language. Languages like Python, Rust, Java etc do extra work to âoeset upâ a âoesafeâ environment (a runtime or VM) and that code is not only invisible upon simple inspection, but varies between runtimes. Python for example just introduced a breaking change into its runtime when doing st

        • Wait, are you GPT-3? Maybe 2?

          What do you mean by "compiles cleanly to predictable ASM"? Do you mean individual lines always output the same assembly in any given context? That hasn't been true for a long time, so you can't mean that. Do you mean that if you follow the steps of the C compiler in a given OS state that you will get roughly the same (the same for all intents and purposes, but things like compile-time constants like, well, COMPILE_TIME might differ) output? Well, yeah, that's called running a pr

        • Rust compiles cleanly to predictable ASM in the same sense. There is no difference. Rust has no VM, or runtime.

        • Comment removed based on user account deletion

    • 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.

    • It's a good scare, but from my understanding, the Rust bindings for the kernel are licensed correctly. Just as building a Linux kernel with the permissively licensed Clang/LLVM is not illegal, neither is using Rustc and its LLVM backend generator. The GPL itself makes exceptions for compilers. The language bindings, the bridge between C and Rust, the main part you'd have to worry about, are not an issue since they're also licensed as GPLv2.

    • Re: (Score:2)

      by jma05 ( 897351 )

      Have you used Rust?
      Rust is an LLVM front end that can compile without using a runtime or standard library. It does not have a garbage collector or a JIT compiling runtime like JVM. No one compares it with Java. Perhaps you are confusing it with Go?
      Rust is not different than compiling C++ with Clang. You can compile without runtime bounds checking in Rust.

      • Rust is not different than compiling C++ with Clang.

        C++ is actually a good example to explain what's at stake.

        One way to look at Rust is as a distant cousin of C++, except where all the memory safety features (shared pointers, bound-checked accessors to vectors, etc.) are mandatory and you need special steps to bring back good old pointers and arbitrary memory locations.

        Such functionality are provided by the C++ STL and/or Boost. Most of it is provided through templates. Some can be completely optimized out, the rest will have code generated on the flight an

        • Re: (Score:2)

          by jma05 ( 897351 )

          > distant cousin of C++, except where all the memory safety features (shared pointers, bound-checked accessors to vectors, etc.) are mandatory and you need special steps to bring back good old pointers and arbitrary memory locations.

          Yes, Rust is in a sense, just C++ best practices codified into the language itself as defaults.

    • 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.

      Absolute nonsense. Your confusing Rust and Go. Rust has no runtime. It is for all purposes a C alternative with similar use-cases with its most notable feature being its type system that puts

    • Re: (Score:2)

      by DrXym ( 126579 )
      You can write GPL code in Rust.

      Secondly, Rust's bounds checking is no worse than properly written C. For example I could loop through elements in an array the only bounds check is where I first stipulate the range I want to iterate. If the range is constant and known to the compiler then it doesn't even generate a runtime check because there is no need. I could also use slices to reduce what I want to iterate, or iterator patterns, or some other construct where I'm basically processing data in a sensible

      • Even if the range isn't constant but the compiler can determine it's constant within the loop, it can insert just a single check on entry. Rust has a lot more scope in this regard because of no aliasing and far more extensive inferencing than is common or even possible for a C compiler.

        • Re: (Score:2)

          by DrXym ( 126579 )
          That's what I meant about the range check above. If the code said "for v in &values[start..end]" then the runtime will check start / end when it makes the slice before entering the loop. The loop itself is essentially just a pointer iterator at that point. The compiler will also borrow the slice as immutable to prevent the code from modifying the vec while it is being iterated. Therefore the slice is always valid and the generated code is basically equivalent as correct C.

          • Yep. I hope everybody reads and understands your example. Succinctly illustrated.

            • Going back to your "properly written C" comment... many C programmers will reason out complex chains of logic to prove to themselves that their loop cannot possibly go out of bounds. Then neglect to document that logic, which rots, then voila: exploit! In many cases, Rust does not let you get away from neglecting to document, at least at that level.

    • Comment removed based on user account deletion

    • GPL v2 or compatible, dumbass.

  • Let's see how it goes (Score:5, Insightful)

    by gweihir ( 88907 ) on Monday September 19, 2022 @05:59PM (#62896381)

    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.

    • 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:Let's see how it goes (Score:5, Interesting)

        by The Evil Atheist ( 2484676 ) on Monday September 19, 2022 @06:56PM (#62896547)
        The biggest issue the kernel faces IS maintenance. It's perhaps THE biggest issue in all of software engineering. Software at the bottom of the stack cannot go through the same amount of breakage as your crappy website at the top of the stack.

        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)

          by Tablizer ( 95088 )

          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:3)

          by gweihir ( 88907 )

          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

        • 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.

          I wish I had enough mod points to mark you as +6 interesting. This is EXACTLY what will happen. I see the same issue every day at work in other areas than kernel hacking.

          • Sure, why not endorse a viewpoint that is completely wrong? At least you have company.

            • Sure, why not endorse a viewpoint that is completely wrong? At least you have company.

              LOL. Nah, you are wrong. Nananana I can't hear you...

              Is this REALLY the level of discourse you wish to engage in? Why? Why not say WHY you think the idea is wrong. Just saying it is wrong is not an argument, it is a statement.

              I am not wrong. I have seen similar scenarios play out over the years at various places I have worked. Since you do not have access to that data, let's look at an instance that is very public: Python

              The fork from version 2 to version 3 took place over a decade ago IIRC. To this very da

              • If you doubt that kernel devs will work with Rust devs to keep it from forking then you are the driveling idiot everybody thinks you are.

    • For example the language can effectively fork into a Linux kernel version and a general use version

      That's not how extensions work. Linux uses several GNU only C extensions [gnu.org]. We don't call that Linux-C we just call it C with extensions. So the thing you're talking about. That has already happened with C and the Linux kernel. Even then things like printf, the kernel doesn't use gcc libc or literally any standard of printf for C, they just write it themselves and we slap a k [kernel.org] on the end. Same diff with some of the Rust stdlib in the kernel. So what you are talking about isn't a thing. We all just agre

      • Or the Rust code in the kernel has to be written a lot different from regular Rust code

        Sort of, but no different than C macros that have to be used by the kernel for all kinds of things.

        That's actually the funny part. You have to give up the protections that make it different from C. So yeah, it's the same as C, but... according to the Rust people that means it is really awful! lol

        • You have to give up the protections that make it different from C.

          Only when trusting some other part of the kernel, which has handed you data. Everything you create and use inside the Rust code can make use of the protections.

          • lol right, that's true... "only" when your code involves either an input or an output!

            • That is incorrect. Any data which is output will be subject to protection, until it has left the Rust code. That Rust is bad because it does not have magical properties and extend the protection into C code it has not compiled is hardly an argument any sane person would make.

              The one time data can not be subject to compile time protection is at the moment they enter Rust code from the outside. This in no way prohibits runtime protection, and after the data is in the Rust code, it will be subject to protectio

        • You have to give up the protections that make it different from C

          That is distinctly untrue. You can read all about writing an OS in Rust [phil-opp.com] for yourself. You can check the code of Redox [redox-os.org] yourself. That is just plainly false. You can choose the level of protections you want in your code, it does mean that for some functions there must be wrappers that support that. But the same is true in C. The kernel has to low level what we all just assume to exist with the C runtime library, hence why we have things like printk(). The kernel has to fastcall functions in C, it's not

          • You don't understand the issues well enough to know what I was referring to, and you're gonna refute me by blowing bubbles?

            You know you do not have the domain knowledge to know if your conclusions are true. Otherwise, you wouldn't say that. The thing you linked to doesn't speak to me point. Sure, if you write an OS in Rust, without using any C, blah blah blah. But that's not what we're talking about here.

            You blah blah blah without having understood what I said. When you're talking about code and a firmwar

            • I cannot even make sense of anything you've said. Perhaps proofread your comment a bit and get back to me?

              a firmware engineer makes a statement

              LOL Well thanks for the flashing "I'm a firmware engineer" badge. Oh look, I've done that too. What a small world.

              So your argument, if I can understand it, is "I'm smarter than you, ergo I'm right." Cool argument. You know what I'll just let you have this one if you promise not to toss any more word salad.

      • Re: (Score:2)

        by gweihir ( 88907 )

        I do not think

        That is accurate. Your "arguments" are bogus and boil down to "I deeply believe in this". C is an entirely different beats than Rust, and that is the whole point of starting to use Rust. Hence the observations for C do not transfer.

        • That is accurate. Your "arguments" are bogus and boil down to "I deeply believe in this".

          That's literally the same of your arguments. What kind of rebuttal is that?

          C is an entirely different beats than Rust

          This basically boils down to "C is different because I said so, ergo, Rust can never be right and always be wrong, because C is is different". It's so circular and based on no fact what-so-ever.

          Hence the observations for C do not transfer

          Zero rationale given outside of the circular logic you have previous applied.

          This is so pitiful a response. I get it, some people don't like Rust. Fair. Happens to everyone when something new comes around. But if you got into the compute

          • Re: (Score:2)

            by gweihir ( 88907 )

            I point you possibilities, you claim I am wrong. That means you have to supply evidence, while I do not. Yes, I get that understanding this subtle difference is probably out of mental reach for you.

            • I point you possibilities, you claim I am wrong

              Yes that was my first comment. I addressed them and indicated that all that you raised was already considered. You said, that my arguments had no substance because C is a magical language. The ball is back in your court.

              That means you have to supply evidence, while I do not

              If I do, which I did, you can't just hand wave it away and say, "Nope I don't accept it and I'll provide no reason as to why I don't accept it outside of C is different."

              Yes, I get that understanding this subtle difference is probably out of mental reach for you

              No you're just hand waving away any rebuttal thinking you have some upper hand.

              I point you possibilities

              Hence the observations for C do not transfer [LITERALLY NOTHING ELSE PROVIDED]

              You have provided nothing, I've given yo

    • Rust kernel devs and Rust language devs work together closely to ensure that the language evolution goes in the correct directly for everybody, and that it stays as one language. Where Rust is extended to accommodate kernel needs I have no doubt that these extensions will be well thought out and broadly applicable.

  • Hooo boy this comment section is gonna be fun.

  • 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:3)

    by devslash0 ( 4203435 ) on Monday September 19, 2022 @06:27PM (#62896467)

    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?

    • The link in the story was to Phoronix. They did two tests on an I/O driver. They were doing IRQ and polled-mode tests. Mike's results are nicely graphed and seem perfectly legitimate. It does seem like a bit of light testing and the C results were, in fact, a little better. Would that "little" stack up to a lot under certain scenarios? I'm guessing Linus would be the best one to predict that. He's the pragmatic type. So, if it turns out to be worse in any of the terms you or I mention, I think he'd be big e

    • Well, that's obvious, right. The reason for writing a new driver for something that already exists is to trial how well the Rust one works. It's not designed for production use, it's an experiment I think. That makes sense. You don't write a new driver in a new language in a new area where there is nothing to compare with, not as a first one.

    • Re: (Score:2)

      by DrXym ( 126579 )
      The intention of the new driver was to implement something already written in C and compare like for like performance. They're not expecting people switch drivers, although time that might happen. As for the comparison - the driver written in Rust performs virtually the same as the C driver which should allay concerns that it imposes runtime overheads of some sort - it doesn't. What it also shows is that Rust can be used to implement non-trivial kernel code and that using Rust will allow developers to avoid

  • How hard would it be to exclude Rust in a custom kernel?

  • One thing I have observed on some open source stuff is that, over time, different developers add-in the libraries they like, and add-in code they've written in other languages, and the dependencies grow. Build times and complexities grow (though to be fair many do not notice this effect as they upgrade their dev systems) - so that eventually it becomes a total pain to build the project and the opportunities for clashing dependencies and/or dependencies on no-longer-supported stuff mount.

    Just how many langu

    • Re: (Score:2)

      by vbdasc ( 146051 )

      Just how many languages (and interpreters/compilers/libraries) will eventually be required to build a Linux system? Will anybody who is not a Kernel maintainer be able to do it, or will it eventually be like closed-source code with everybody downloading prebuilt binaries and nobody looking at the sources?

      IMHO, everybody downloading pre-built binaries is a different thing from nobody looking at the sources, and these two things are barely related, if at all.

      By the way, are you implying that everyone who compiles their own kernel actually looks at the sources? This would be very far from the truth.

      • Re: (Score:2)

        by tiqui ( 1024021 )

        "are you implying that everyone who compiles their own kernel actually looks at the sources?"

        No, just that the one behavior tends to lead to or encourage the other - when nearly everybody downloads the pre-built stuff, very few will be building it and therefore fewer people are likely to bother with the source. There's likely a subset of coding-capable folks who, if they were to download the sources, might build them and for some reason end up looking at the sources (like encountering a build issue on the

  • ... on the language itself after he's used it for something critical. Linus is an all-out C developer like only few others, but people say that Rust as a systems language does everything right what C does wrong and then some. Linus has had very good reasons for sticking with C, but Rust seems to me like a candidate Linus could appreciate as a C replacement for himself too. I'd be curious on his opinion after real- world experience in crucial kennel work.

  • You can tell what the code compiles to in assembly. Is this possible with Rust?

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close