More Rust Code Is Coming For Linux 6.14 Along With Hitting Another "Major Milestone"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    More Rust Code Is Coming For Linux 6.14 Along With Hitting Another "Major Milestone"

    Phoronix: More Rust Code Is Coming For Linux 6.14 Along With Hitting Another "Major Milestone"

    For the Linux 6.13 cycle the Rust code was hitting a "tipping point" with more Rust kernel drivers expected soon. For Linux 6.14 there is indeed a lot more Rust code being primed for this next kernel version...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Steffo
    Senior Member
    • Jan 2013
    • 604

    #2
    I generally had a good opinion of Rust, but this complexity, which comes with system programming, is really disgusting!

    Comment

    • bachchain
      Senior Member
      • Jun 2016
      • 403

      #3
      Before anyone asks


      Currently, the standard library types Rc and Arc are special. It’s not possible for third-party libraries to define custom smart pointers that work with trait objects.

      It is generally desireable to make std less special, but this particular RFC is motived by use-cases in the Linux Kernel. In the Linux Kernel, we need reference counted objects often, but we are not able to use the standard library Arc. There are several reasons for this:
      1. The standard Rust Arc will call abort on overflow. This is not acceptable in the kernel; instead we want to saturate the count when it hits isize::MAX. This effectively leaks the Arc.
      2. Using Rust atomics raises various issues with the memory model. We are using the LKMM (Linux Kernel Memory Model) rather than the usual C++ model. This means that all atomic operations should be implemented with an asm! block or similar that matches what kernel C does, rather than an LLVM intrinsic like we do today.

      The Linux Kernel also needs another custom smart pointer called ListArc, which is needed to provide a safe API for the linked list that the kernel uses. The kernel needs these linked lists to avoid allocating memory during critical regions on spinlocks.

      Comment

      • ssokolow
        Senior Member
        • Nov 2013
        • 5112

        #4
        Originally posted by Steffo View Post
        I generally had a good opinion of Rust, but this complexity, which comes with system programming, is really disgusting!
        Mind elaborating? Your phrasing makes it sound like you're saying that system programming is so disgustingly complex that supporting it is beneath Rust.

        Comment

        • Steffo
          Senior Member
          • Jan 2013
          • 604

          #5
          Originally posted by ssokolow View Post

          Mind elaborating? Your phrasing makes it sound like you're saying that system programming is so disgustingly complex that supporting it is beneath Rust.
          No, you totally misunderstood me. My point is, that system programming with Rust can be more complex than with other system programming languages. Even with C certain things are much simpler implemented than with Rust. Even things like implementing a linked lists are not trivial in Rust. This is more true with system programming where you are in the unsafe realm. Unsafe Rust is really complex and no fun. This is why people think that Zig is more suitable for system programming than Rust.

          Comment

          • Akiko
            Phoronix Member
            • Sep 2017
            • 69

            #6
            Originally posted by Steffo View Post

            No, you totally misunderstood me. My point is, that system programming with Rust can be more complex than with other system programming languages. Even with C certain things are much simpler implemented than with Rust. Even things like implementing a linked lists are not trivial in Rust. This is more true with system programming where you are in the unsafe realm. Unsafe Rust is really complex and no fun. This is why people think that Zig is more suitable for system programming than Rust.
            In short: it is annoying to think all the time about how to please the borrow checker

            Comment

            • phoenk
              Phoronix Member
              • Nov 2016
              • 55

              #7
              Originally posted by Steffo View Post

              No, you totally misunderstood me. My point is, that system programming with Rust can be more complex than with other system programming languages. Even with C certain things are much simpler implemented than with Rust. Even things like implementing a linked lists are not trivial in Rust. This is more true with system programming where you are in the unsafe realm. Unsafe Rust is really complex and no fun. This is why people think that Zig is more suitable for system programming than Rust.
              Here's your non-trivial Linked List:

              Code:
              struct LinkedListNode<T: Sized> {
                  value: T,
                  next: Option<Box<Self>>,
              }
              and if you are writing basically anything besides kernel code, you would just use
              Code:
              std::collections::LinkedList

              Comment

              • kpedersen
                Senior Member
                • Jul 2012
                • 2712

                #8
                Originally posted by Steffo View Post
                This is why people think that Zig is more suitable for system programming than Rust.
                Just look around these forums and you can see I am quite skeptical about Rust and certainly don't hide it. However I am pretty sure that people don't think Zig is more suitable for system programming. Actually, I am pretty sure that people don't think about Zig at all.

                Originally posted by Akiko View Post

                In short: it is annoying to think all the time about how to please the borrow checker
                Its more just pointless when the data you are "borrowing" has come from an inevitable unsafe{} section and is going to be forwarded to an inevitable unsafe{} section (after some dangerous / non-typesafe marshalling). You are already likely "borrowing" an erroneous dangling pointer underneath your reference and don't realize it.
                Last edited by kpedersen; 20 January 2025, 01:45 PM.

                Comment

                • Steffo
                  Senior Member
                  • Jan 2013
                  • 604

                  #9
                  Originally posted by phoenk View Post

                  Here's your non-trivial Linked List:

                  Code:
                  struct LinkedListNode<T: Sized> {
                  value: T,
                  next: Option<Box<Self>>,
                  }
                  This is a struct, not an implementation.

                  Originally posted by phoenk View Post
                  and if you are writing basically anything besides kernel code, you would just use
                  Code:
                  std::collections::LinkedList
                  I was talking about system programming, wasn't I?

                  Comment

                  • Steffo
                    Senior Member
                    • Jan 2013
                    • 604

                    #10
                    Originally posted by kpedersen View Post
                    However I am pretty sure that people don't think Zig is more suitable for system programming. Actually, I am pretty sure that people don't think about Zig at all.
                    It always depends on which bubble you live. Zig is pretty awesome and much better than C and C++. :-) I program in C++ for a living, btw.

                    Comment

                    Working...
                    X