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

[jacob]

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.

[Jabberwocky]

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.

[piotrj3]

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.

[EvilHowl]

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.

[MowKow]

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

[Raka555]

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.

[mirmirmir]

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.

[Raka555]

If a few years I will read about how hard it is to maintain rust code in the kernel ...

[stormcrow]

Rust is not ADA or SPARK (especially that one). Rust only aimed to have memory safety, better concurrency and avoiding few bad design choices like multi-polimorphism and exceptions. Rust was not made to catch all bugs, it was meant to fix memory related issues that are hard to track and fix.

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.

[piotrj3]

It really depends. You can easily shoot yourself into the foot but you can use smart pointers and a crash handler who sends dumps. Most of our crashes happen in the graphics driver. But this are not the serious bugs.

Most serious bugs have their root into code which was hacked under time pressure. They are not crashes but strange behavior. And most crashes are simply running into asserts. I don't see how Rust would fix that. I think more test driven development could help but that is hard to enforce. Nobody wants pseudo tests.

Actually I was surprised that Rust is not stronger on this front. You could do much more on the language level to make testing easier. You can not catch all bugs at compile time. Most input is happening at runtime. So you need tests for that.

Rust is not ADA or SPARK (especially that one). Rust only aimed to have memory safety, better concurrency and avoiding few bad design choices like multi-polimorphism and exceptions. Rust was not made to catch all bugs, it was meant to fix memory related issues that are hard to track and fix.