Announcement

Collapse
No announcement yet.

Asahi Linux May Pursue Writing Apple Silicon GPU Driver In Rust

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

  • #41
    Originally posted by dragon321 View Post
    I wonder if people that are against writing drivers in Rust because "Such important thing as driver should be written only in C" would be against C years ago saying "Such important thing as driver should be written only in Assembler".
    So true. Out of all dead-end, uninspired and downright backwardly technologies that computer science created in the past ~10 years, Rust is one of the few exceptions that is worth adopting.

    Comment


    • #42
      Originally posted by rene View Post

      only Redox & friends ;-)
      And now Windows.

      Comment


      • #43
        For me it is perfect case scenario to make Rust proven. We have actual needed use case for Rust here, that driver only exist on ARM CPUs so limited scope of support for Rust is absolutly not an issue and never will be.

        Comment


        • #44
          I don't like to learn new things so hate Rust, but actually have a technical reason on why Rust is the wrong choice: other operating systems working on the M1 or M2. OpenBSD has a port for the Mac M1 and I think NetBSD does too. They will never accept a rust driver into their OS so why not stick to C so everybody can benefit?

          Comment


          • #45
            Originally posted by kpedersen View Post

            Sure, you say that Rust excels in this but lets wait and see them actually implement this whilst being able to access the required data without resorting to unsafe. This will be the only evidence.
            The unsafe part is the driver going to be addressing the necessary GPU registers/memory locations directly and/or directly doing underlying syscalls. This is always going to be unsafe, its literally impossible for it to not be (how are you going to prove to a compiler that pointing/addressing to some hardcoded memory location/pointer is "correct"?). Thats not why Rust is useful and is not even a point that actual sane people/programmers even contest, its just a stupid strawman that is brought up by people who don't know what they are talking about.
            Last edited by mdedetrich; 12 August 2022, 06:12 AM.

            Comment


            • #46
              Originally posted by kylew77 View Post
              They will never accept a rust driver into their OS so why not stick to C so everybody can benefit?
              because we shouldn't cripple ourselves to suit the needs of others. if they want the good stuff people will contribute to linux, they will use the good stuff people contribute to linux. rust or not.

              Comment


              • #47
                Originally posted by kylew77 View Post
                I don't like to learn new things so hate Rust, but actually have a technical reason on why Rust is the wrong choice: other operating systems working on the M1 or M2. OpenBSD has a port for the Mac M1 and I think NetBSD does too. They will never accept a rust driver into their OS so why not stick to C so everybody can benefit?
                "Not my problem"

                Comment


                • #48
                  Originally posted by kylew77 View Post
                  I don't like to learn new things so hate Rust, but actually have a technical reason on why Rust is the wrong choice: other operating systems working on the M1 or M2. OpenBSD has a port for the Mac M1 and I think NetBSD does too. They will never accept a rust driver into their OS so why not stick to C so everybody can benefit?
                  A modern Linux GPU driver will be built around Linux' DRM infrastructure. Porting this over to other OS'es will require a lot of modifications anyway. A developer porting this to another OS may perhaps benefit from porting code that went through Rust's borrow checker and is therefore much less likely to contain invalid memory access issues, race conditions etc.

                  Comment


                  • #49
                    Originally posted by mdedetrich View Post

                    The unsafe part is the driver going to be addressing the necessary GPU registers/memory locations directly and/or directly doing underlying syscalls. This is always going to be unsafe
                    I want to add something on this point, considering that there is a bit of confusion about unsafeness in Rust, a thing that always produces threads with hundreds of angry anti-Rust comments.

                    The unsafe in Rust, means that the compiler cannot guarantee anything about the inner workings of the code and the accesses to the state of the components manipulated by that code.

                    It basically means that the programmer is on his own and must pay A LOT of attention to what his code does. But in engineering there is a practical principle stating that small systems are easy to reason about. This is why unsafe code MUST be small, do as fewer things as possible and the programmer must spend the necessary time testing and reviewing the code and how it interacts with the "external" world. Possibly defining clear protocols by which code components share state.

                    And as soon as possible, encapsulate this code into safe interfaces, so that users of the code can use it safely.

                    This is the greatest revolution Rust puts on the table. If we take strings in Rust, they are just vectors. They are safe from the "storage" point of view, because they use Vec that encapsulates the unsafeness of building and accessing dynamic length sequences of elements and makes working with them safe.

                    But strings in Rust are UTF-8 encoded too. And UTF-8 has specify rules about what constitutes valid codepoints and sequences of codepoints. So, internally, strings are unsafe from the point of view of what codepoints are stored inside them, meaning that the code that implements strings spares no effort to verify that what is stored into a string is legal UTF-8. And again, it encapsulates this unsafe behavior into safe interfaces. This means that users of the String type can use it safely.

                    Obviously everything can have bugs, even unsafe Rust code. But it is easier to find and squash bugs in small, well defined portions of code. And as soon as you encapsulate them into safe interfaces, you can leverage the Rust compiler to guarantee that the users of your "library code" can only use it safely.

                    So unsafe doesn't mean that everything using unsafe code is unsafe ( a common misconception a lot of Rust haters seem to believe ). This would defeat the reason d'etre behind Rust.
                    Last edited by pabloski; 12 August 2022, 09:42 AM.

                    Comment


                    • #50
                      You can always count on fellow Phoronix commenters to know better than the one doing the actual work..

                      Comment

                      Working...
                      X