Announcement

Collapse
No announcement yet.

Initial Support For The Rust Language Lands In Linux-Next

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Initial Support For The Rust Language Lands In Linux-Next

    Phoronix: Initial Support For The Rust Language Lands In Linux-Next

    For a long while now Linux kernel developers have discusses the prospects of optionally allowing the Rust language to be used for new device drivers within the Linux kernel areas and other areas within the kernel for this language that prides itself on safety and performance. As the first baby step towards that dream, initial Rust support appeared this week in the Linux-Next tree...

    https://www.phoronix.com/scan.php?pa...its-Linux-Next

  • #2
    Drivers with built-in memory safety? I'll take two, tyvm.

    Comment


    • #3
      Typo: Currently the kernel upport needs a recent nightly Rust toolchain for building.

      Comment


      • #4
        And so its finally time to re-write drivers in rust

        Comment


        • #5
          Hopefully, we won't see the "unsafe" keyword in the code too often. Otherwise the kernel can just keep using C.

          Comment


          • #6
            Originally posted by Quackdoc View Post
            And so its finally time to re-write drivers in rust
            Finally? It's the first step of the proof of concept, we are far from "finally".
            But we're past dismissing Rust and now giving it a fair chance to prove itself worthy.

            Comment


            • #7
              Originally posted by 60Hz
              Rust is bad solution to a self-inflicted problem...
              What is self-inflicted about the problems rust intends to solve?

              Comment


              • #8
                Originally posted by Quackdoc View Post
                And so its finally time to re-write drivers in rust
                It is going to be a long long long time before any significant number of drivers would be rewritten, but this will allow newer drivers that are intended to run on the (currently supported) arm64 and x86_64 architectures to be written in rust in the future. Anything that potentially lowers the barriers to entry for development and ongoing support of new/additional hardware should be considered goodness to the Linux ecosystem.

                Comment


                • #9
                  Originally posted by CommunityMember View Post
                  Anything that potentially lowers the barriers to entry for development and ongoing support of new/additional hardware should be considered goodness to the Linux ecosystem.
                  YES, bring on the drooling idiots who decide to declare themselves masters^H^H^H^H^Hins of kernel development!

                  BTW, does anybody know why rustc shows up in top as always being in the "S" sleeping state, but simultaneously using up 100% (or more) CPU? Why doesn't rustc act like a normal process?

                  Comment


                  • #10
                    Originally posted by kiffmet View Post
                    Hopefully, we won't see the "unsafe" keyword in the code too often. Otherwise the kernel can just keep using C.
                    You will see it many times for sure, some things kernel needs to do like accessing hardware registers is unsafe by nature and requires unsafe code. As an example you can browse Redox code (an operating system entirely written in rust) and you will find hundreds of occurrences of unsafe keyword.

                    https://gitlab.redox-os.org/redox-os/redox

                    But if you calculate the percentage of code in unsafe blocks with respect to the entire codebase, the number will be very small. And if a memory error happens, you know you have to look only inside the unsafe blocks. That's a huge win!

                    Comment

                    Working...
                    X