Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Linux

Greg Kroah-Hartman Sees 'Tipping Point' for Rust Drivers in Linux Kernel (phoronix.com) 42

Greg Kroah-Hartman noted some coming changes in Linux 6.13 will make it possible to create "way more" Rust-based kernel drivers. "The veteran kernel developer believes we're at a tipping point of seeing more upstream Rust drivers ahead," reports Phoronix: These Rust char/misc changes are on top of the main Rust pull for Linux 6.13 that brought 3k lines of code for providing more Rust infrastructure. Linux 6.13 separately is also bringing Rust file abstractions.
"Sorry for doing this at the end of the merge window," Greg Kroah-Hartman wrote in the pull request, explaining that "conference and holiday travel got in the way on my side (hence the 5am pull request emails...)" Loads of things in here...

— Rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present.

Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)

Greg Kroah-Hartman Sees 'Tipping Point' for Rust Drivers in Linux Kernel

Comments Filter:
  • by gweihir ( 88907 ) on Sunday December 01, 2024 @02:48PM (#64983649)

    ... is such a great idea. I am still convinced Linus is essentially just giving the Rust-fanatics enough rope to hang themselves.

    • Yup, it has taken linux 30 years to get this far, but hey let's mess with it.
      • by Jeremi ( 14640 )

        Yup, it has taken linux 30 years to get this far, but hey let's mess with it.

        It took linux 30 years of people messing with it to get it this far. You can't improve things unless you are willing to change things.

        • How is it an improvement to add a memory safe language in a field where people already understand how to handle memory? Anyone programming at the os or driver level will understand that. In the application layer maybe not so much.
          • by gweihir ( 88907 )

            Well, sort of. The kernel core (for lack of a better word) is has basically no need for Rust, anybody able to do anything there is highly competent and generally does not make beginner's mistakes. On the other hand, drivers are a bit of a different story. But remember that drivers are easy to rip out, so this is more "Rust on the side of the kernel" than "Rust in the kernel", no matter the propaganda crap the Rust fans are pushing.

            My take is this will eventually, in a few years, fail. Rust is too hard to le

          • by Jeremi ( 14640 )

            How is it an improvement to add a memory safe language in a field where people already understand how to handle memory?

            It's not enough to understand how to handle memory correctly -- you have to also handle memory correctly. 100% of the time. Forever. And everyone else who touches the codebase has to as well.

            Anyone who thinks they are capable of doing that is kidding themselves. Real humans, even the best ones, make mistakes. Experienced programmers understand that, and adopt tools that help them reduce the likelihood of mistakes going uncaught and making it into production.

            • It's not enough to understand how to handle memory correctly -- you have to also handle memory correctly. 100% of the time. Forever. And everyone else who touches the codebase has to as well.

              That's called being a developer.

              • by Jeremi ( 14640 )

                That's called being a developer.

                In that case, there are no developers on Earth, because nobody (but nobody) writes bug-free code 100% of the time.

                (and I say this as someone who has spent the last 25 years doing C++ programming full-time)

    • by test321 ( 8891681 ) on Sunday December 01, 2024 @03:17PM (#64983707)

      Rust in linux will bring more stability to the language because the backers of the Rust foundations are also important contributors to the linux kernel (Google, Meta, Huawei, Microsoft).

      • by gweihir ( 88907 )

        Probably. But that is ass-backwards.

      • by PPH ( 736903 )

        Rust in linux will bring more stability

        Or it will kill linux. Much to the joy of Google, Meta, Huawei, and Microsoft. Who I'm sure have proprietary solutions waiting in the wings.

        • by test321 ( 8891681 ) on Sunday December 01, 2024 @07:05PM (#64984119)

          I don't believe that Google or Meta are interested in complicated ways to kill linux. They could replace linux with something else any day they want in the clear without strange conspiracies, yet they're not doing it. Amazon is also a backer of the Rust foundation, and although it is not a contributor, it is a heavy user and does not want to disrupt its cash flow with a failing linux.

          Microsoft might want to kill linux, but then money talks and Azure is their cash cow, like AWS for Amazon.

          Your argument might apply to Huawei, they don't need linux for their smartphones anymore, and they might seek revenge.

          • by batkiwi ( 137781 )

            Why would Microsoft want to kill linux? It gives them a free OS with minimal investment to power their real money-making endeavours, plus it gives someone else to point the finger at for issues. Best of both worlds.

            Sure they lose windows server licensing revenue, but that is tiny in the scheme of things.

      • Google, Meta, Huawei, Microsoft

        These are not the groups I would rely on to keep things stable.

    • Stability is of paramount importance.

      I demand to be able to compile and run the exact same segfaults that I was writing in 1974!

      • Maybe not 1974, but if you compiled something in 1997 for Linux, it will probably still run. (If it doesn't, it's because you relied on unstable libraries from Gnome or something). The Linux kernel has made userland stability a priority, and with success.
        • by gweihir ( 88907 )

          Indeed. As good engineering practices would dictate. Of course, if you want to make tons of money selling software, you have to force people on new software and platform version all the time, thereby crappifying the quality of it all.

          • For that matter, there's a reasonable chance you could get a 1974 C program to compile on GCC with the right options; certainly a 1978 program could be compiled. (Incidentally, Donald Knuth prefers K&R C over ANSI C, I think he likes the syntax better somehow).
        • Nothing about this will affect userland. The public APIs aren't changing.

      • Or wrap in in a pagefault, so you can have it in a return value. Then hide it some app helper's i/o stream. Then you can have some platform built around it.....
    • The problem Linus is facing is that there are plenty of incompetent programmers writing drivers. As in, people who only learned C with the express purpose of writing drivers for their company's device. And these people are writing plenty of bugs because of their inexperience, but you don't want to ban them because they are working for free and if they were banned their would be no driver for that particular device.

      So Linus is hoping that Rust will help incompetent developers write better code. And it prob
  • by Gravis Zero ( 934156 ) on Sunday December 01, 2024 @08:15PM (#64984223)

    So long as the Rust is 100% optional for compiling the kernel except for a few oddball modules, I'm OK with this. When something critical becomes Rust only, I will be very much against this because it means needing multiple compilers just to build a the dang kernel.

    • You're implying the kernel isn't already complex to build, requiring downloading a large toolset and a relatively powerful computer (to preserve your own sanity). The people building their own kernels are not usually the type to build only a kernel.

      I don't see any reason why you would draw the line at one compiler. It's a senseless line to draw.

      • I don't see any reason why you would draw the line at one compiler.

        It's not that it's one compiler, it's that it's the only compiler. It's bad enough that GCC is the only C compiler that can build Linux (despite efforts to make Clang capable) but to make two specific compilers to build the kernel is nuts and completely destroys any chance of build portability.

        • by myrdos2 ( 989497 )

          We should then rewrite the kernel entirely in Rust. I predict that this will make you happy.

        • What problems do you see from gcc being the only compiler from linux? I mean, supporting multiple compilers is an effort. And what do you gain?

          It was clearer in the past -- different platforms had different compilers, and you would want to avoid vendor lock in. But gcc works for everywhere and it is free software so vendor lock in is less of a problem.

          I can see a few theoretical advantages -- supporting clang might give some performance advantage, or build quicker. Similarly for Rust supporting gcc would gi

          • "gcc works for everywhere" is a lie. GCC works for most platforms but not all of them. Furthermore, GCC doesn't have all the features one may desire in a build like the formally verified builds that CompCert generates.

            Similarly for Rust supporting gcc would give a wider range of targets

            Reliance on the Rust compiler drastically reduces the number of supported platforms. You can check out the list of supported platforms on their page and most are unsupported while many have poor support. This means if it doesn't compile for your platform non-standard platform then you are effe

            • Well, I am sure you are correct that there are some targets that gcc doesn't support, or doesn't support any more. So, linux won't run on them. Can you tell me one platform that you have felt linux could support but doesn't because of it's use of GCC?

              Compcert I didn't know about, but yes, something formally verified seems nice, although as it does not produce highly optimized code that seems like a niche; but something that might be good in the future.

              Of course, you are correct that adding in Rust/LLVM woul

              • Can you tell me one platform that you have felt linux could support but doesn't because of it's use of GCC?

                Off the top of my head, Epiphany-III and XCore. They may be obscure but these were both made by small startups and they only developed LLVM backends which means porting linux was never even an option. There is a good reason they went with LLVM too, GCC is a monster.

                It took many years before RISC-V got a half-decent GCC port.

    • by martin-boundary ( 547041 ) on Monday December 02, 2024 @05:45AM (#64984645)
      In other news, Lennart Poettering has just announced that systemd will be completely rewritten in Rust, starting in January.
      • by butlerm ( 3112 )

        I will be sufficiently impressed with Rust when one can successfully do a nearly one for one translation of C and/or C++ code to idiomatic Rust code without breaking anything. Until then not so much. Of course many such functions would necessarily be unsafe but certainly not all of them, even in a code base like the Linux kernel.

I'd rather just believe that it's done by little elves running around.

Working...