Announcement

Collapse
No announcement yet.

LPC 2022: Rust Linux Drivers Capable Of Achieving Performance Comparable To C Code

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

  • #21
    Originally posted by Raka555 View Post
    If a few years I will read about how hard it is to maintain rust code in the kernel ...
    I heard that most popular rust libs haven't been updated in years, simlly because they are complete.

    Comment


    • #22
      Originally posted by mirmirmir View Post

      I heard that most popular rust libs haven't been updated in years, simlly because they are complete.
      Go ask the ReduxOS people why their stuff won't compile 90% of the time.

      Comment


      • #23
        Originally posted by zcansi View Post
        For people asking why C++ is not used, my personal take on C++ is that it has more abstraction capability just like Rust, but the abstractions you build with C++ are leaky, in other words you still need to understand many details of the abstraction to use it correctly.
        Well said, but atm I still prefer the added flexibility C++ offers me, especially templates and other compile time abstractions

        concerning memory safety:
        virtually all issues I'm running into are due to having to interface into C APIs using raw pointers, so Rust really won't help me there

        Comment


        • #24
          Originally posted by zcansi View Post
          IMO the main reason why NVMe is an interesting test case is that it is representative of any driver for modern high-speed hardware, with multiple I/O queues to be managed.

          For people asking why C++ is not used, my personal take on C++ is that it has more abstraction capability just like Rust, but the abstractions you build with C++ are leaky, in other words you still need to understand many details of the abstraction to use it correctly. Rust on the other hand is a little less expressive but focuses on allowing you to build watertight abstractions that you can absolutely rely on. That makes the pain/gain ratio much more favorable, at least in my opinion.

          Of course in the end, the reason why C++ is not used is that Linus does not like C++, and he has his own reasons. He is undecided but open minded about Rust.
          Linus tried C++ once 30 years ago and he decided C++ is a very bad language for kernels. He might have been right then, but things have changed a lot over the last three decades. No, nobody is going to use any runtime features in a kernel, such as exceptions, virtual functions or dynamic casts.

          But still, there are many features of modern C++ that would come in handy on kernel development that will make the mantainers' lifes way easier. There are many open source operating systems (like SerenityOS) that make use of C++ features on their kernels, like the improved type safety over C, namespaces, constructors, templates (those shady and type unsafe macros should have been long gone in any kernel nowadays), RAII (the best C++ feature in my honest opinion) and they are more than happy with C++.

          I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.

          Comment


          • #25
            Originally posted by stormcrow View Post

            Arguably neither is Ada nor Spark meant to catch all bugs. They're (Ada, Spark, Rust, etc) just meant to catch more problems and flaws than what came before. There's really nothing going to stop logic flaws in program design, for example, other than better education on programming logic and a good grasp of the problem domain. There are plenty of professional programmers out there that don't know how to create proper logic charts for programs. Better, safer, and more precise tools, better education, make for better end results. C was a very blunt instrument created in a time when we were just figuring out how to tell computers how to do anything at all. C++ was meant to plaster over C's problems and ended up adding more of its own (by putting too much trust in the programmer). Unfortunately what happened with the development process and forced implementation of Ada poisoned the well for a long time to come. C/C++ was "good enough" and it was what hardware makers were targeting with their optimizations. It didn't help that people that should have known better were and still are worshiping at the altar of C with all the excuses and massive efforts to "fix" what's essentially unfixable. Humans are fallible. Humans will always make mistakes. There isn't a single programmer out there that can write flawless C or C++ code 100% of the time day in and day out no matter how experienced they are. That's why we need safer tools to protect ourselves from our own inattention and foolishness. More safely implemented languages are one such tool. The industry needs to move past the egos (and profit/performance at all costs) and focus on the science of what works and what isn't working.
            Well in case of SPARK aim was to make code exactly what you wrote - testable and verifiable to farthest possible point. Of course if you make logical error SPARK will not save you from that, but SPARK aims to have everything verifiable and all outcomes always checked. This is why it is used in aviation and aviation has close to none crashes because of bugs. Also nvidia use it for firmware.

            Comment


            • #26
              Originally posted by stormcrow View Post

              Arguably neither is Ada nor Spark meant to catch all bugs. They're (Ada, Spark, Rust, etc) just meant to catch more problems and flaws than what came before. There's really nothing going to stop logic flaws in program design, for example, other than better education on programming logic and a good grasp of the problem domain. There are plenty of professional programmers out there that don't know how to create proper logic charts for programs. Better, safer, and more precise tools, better education, make for better end results. C was a very blunt instrument created in a time when we were just figuring out how to tell computers how to do anything at all. C++ was meant to plaster over C's problems and ended up adding more of its own (by putting too much trust in the programmer). Unfortunately what happened with the development process and forced implementation of Ada poisoned the well for a long time to come. C/C++ was "good enough" and it was what hardware makers were targeting with their optimizations. It didn't help that people that should have known better were and still are worshiping at the altar of C with all the excuses and massive efforts to "fix" what's essentially unfixable. Humans are fallible. Humans will always make mistakes. There isn't a single programmer out there that can write flawless C or C++ code 100% of the time day in and day out no matter how experienced they are. That's why we need safer tools to protect ourselves from our own inattention and foolishness. More safely implemented languages are one such tool. The industry needs to move past the egos (and profit/performance at all costs) and focus on the science of what works and what isn't working.
              I agree with the first part of your comment, that a major problem with system problems are lack of understanding within the domain. In many project people come and go very quickly. I have seen extremely valuable knowledge leaving projects so many times in the past decade. Most project owners do not comprehend the degree of impact this has on their projects.

              The second part of your comment you seem to have successfully converted a logical problem into an emotional problem. C and C++ paradigms are day and night apart. Some industries favour the one over the other. I've been working on rapidly changing network and finance systems. Procedural designs are objectively better suited for those environments. There are other systems/environments where highly abstracted paradigms works better, like some databases and 3D game engines where a big part of the code/design doesn't change overnight and where it is somewhat acceptable to break compatibility with major releases, opposed to network/finance where backwards compatibility is mostly mandatory.

              The third part: "More safely implemented languages". It really depends on the domain. With regards to OS/drivers I agree with more checking. In rapidly changing PoC web-clients or web-APIs... I don't think more checking is required. Non-strick JSON structure parsing is what that world requires to innovate.

              Comment


              • #27
                Originally posted by EvilHowl View Post

                I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.
                I don't know by what logic language A "should" be accepted if language B is. Kernel developers are not there to try to prove some point about C++, they weigh the pros and cons of what a new language can bring to the kernel and it's development process. Linus rejects C++ for his reasons (and of course if you believe that he hasn't seen any C++ since 30 years ago you couldn't be more wrong). He obviously sees a benefit in adopting Rust and that doesn't imply anything about C++ or anything else, not even about Rust as such. Only about whether he thinks it would be good to use Rust within the kernel.

                Comment


                • #28
                  Originally posted by EvilHowl View Post
                  ...

                  But still, there are many features of modern C++ that would come in handy on kernel development that will make the mantainers' lifes way easier. There are many open source operating systems (like SerenityOS) that make use of C++ features on their kernels, like the improved type safety over C, namespaces, constructors, templates (those shady and type unsafe macros should have been long gone in any kernel nowadays), RAII (the best C++ feature in my honest opinion) and they are more than happy with C++.

                  I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.
                  I speak as someone who is pretty good with C (including the kernel dialect) and Rust, and has twice bounced off learning C++. I'm not strictly *against* C++ in a kernel context, but I do think you may be underestimating the degree to which Rust is different from C++ (and C). A novice can absolutely not write correct C++ in my personal experience, not even in an existing project with expertly informed coding standards and code structure. While Rust is designed from the ground up to help the compiler prevent people from making the kind of costly, hard-to-debug mistakes which people run into time and time again while learning C/C++, an then very occasionally even at the expert level. Just my personal experience, take it for whatever it's worth, but that's in my opinion a much bigger deal than the slightly improved syntax and quality of life (and, admittedly, some code patterns which help prevent some of C's problems) C++ brings.

                  C++ is an incremental change, Rust is a fundamental rearrangement of priorities.
                  Last edited by zcansi; 13 September 2022, 07:40 AM.

                  Comment


                  • #29
                    Originally posted by EvilHowl View Post
                    Linus tried C++ once 30 years ago and he decided C++ is a very bad language for kernels. He might have been right then, but things have changed a lot over the last three decades. No, nobody is going to use any runtime features in a kernel, such as exceptions, virtual functions or dynamic casts.

                    But still, there are many features of modern C++ that would come in handy on kernel development that will make the mantainers' lifes way easier. There are many open source operating systems (like SerenityOS) that make use of C++ features on their kernels, like the improved type safety over C, namespaces, constructors, templates (those shady and type unsafe macros should have been long gone in any kernel nowadays), RAII (the best C++ feature in my honest opinion) and they are more than happy with C++.

                    I don't think they are doing things wrong by using C++, like Linus once said. Should they be using pure and inmaculate C89, like Linux until a few months ago? If Rust code is accepted, modern C++ code should be as well.
                    Problem here is the Linux kernel is not pure C.
                    https://en.wikipedia.org/wiki/Sparse
                    Linux kernel has been C89 + Sparse extras for quite some time. Migrating to C11 means not having to implement more checking features in Sparse. Do note Linus Torvalds wrote sparse in 2003.

                    Migrating to C++ does not cover the issues that sparse detects. So C++ you would have to implement C++ version of sparse. Welcome to hell.

                    Interesting enough rust developers slide page 61
                    https://lpc.events/event/16/contribu...LPC%202022.pdf
                    Is worth a note.

                    Note that direct going from rust code to Linux kernel code is totally forbid. So in the rust crate there can be sparse rules to make sure you code is not doing anything known to be stupid.

                    Please note sparse is also just the tip of iceberg here. You have Linux kernel added gcc plugins that check for Linux kernel known issue as well.

                    The Linux kernel uses a highly extended version of C. Lot of the features you say are good in C++ makes processing all the extra language limitation rules that the Linux kernel developers have added massively harder to get the same result.

                    Comment


                    • #30
                      Originally posted by bug77 View Post

                      Exactly. The discussion should not be centered around performance, it should be about time-to-market. How long does it take to write (and fix) C vs Rust code. That is where C leaves you hanging while Rust's compiler bends over backwards for you.
                      Don't get me wrong: there will also be performance *benefits* to using rust over C.

                      But it's going to take a fair bit longer for that particular advantage to materialize. Lots of compiler bugs to fix and infrastructure to build.
                      Last edited by Developer12; 13 September 2022, 09:29 AM.

                      Comment

                      Working...
                      X