Originally posted by Raka555
View Post
Announcement
Collapse
No announcement yet.
LPC 2022: Rust Linux Drivers Capable Of Achieving Performance Comparable To C Code
Collapse
X
-
Originally posted by zcansi View PostFor 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.
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
-
Originally posted by zcansi View PostIMO 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.
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.
- Likes 3
Comment
-
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.
- Likes 1
Comment
-
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.
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
-
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.
- Likes 5
Comment
-
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.
C++ is an incremental change, Rust is a fundamental rearrangement of priorities.Last edited by zcansi; 13 September 2022, 07:40 AM.
- Likes 10
Comment
-
Originally posted by EvilHowl View PostLinus 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.
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
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.
- Likes 3
Comment
-
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.
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.
- Likes 1
Comment
Comment