5 ms·
Converting the Kernel to C++
- TwentyPosts 3y agoPlease, anything but that. I find it hard not to view stuff like this as a "if Rust gets to be in the kernel, then so should C++!".
- synergy20 3y agoUsing a small set(kernel-c++20) it can simplify the existing C code by quite a bit, you get ctor, dtor, class inheritance etc all for free. Currently the kernel is basically in object-oriented C anyways.
- moomoo3000 3y agoAre you referring to a specific subset of C++?
- synergy20 3y agoThere is nothing pre-defined, but it's not hard to scope one either, basically a freestanding c++20 will do most of it already, just disable exceptions rtti etc.
- azamba 3y agoOld but gold https://harmful.cat-v.org/software/c++/linus https://harmful.cat-v.org/software/c++/linus
- Night_Thastus 3y agoEDIT: I failed to notice the date stamp, you can ignore this. Jeeze. Linus writes like C++ killed his dog or something. There's plenty of great C++ 'wins' over C that make just doing everyday programming tasks so much easier and simpler for no cost. You don't need to write so abstract and in the clouds that it becomes impossible to maintain - I certainly don't. And frankly, you can shoot yourself in the foot just as easily with C, just in different ways. To be clear: I'm not saying the kernel needs C++, I'm not qualified to write on that specifically. But I am saying C++ is not nearly as bad as he makes it out to be.
- vidarh 3y agoNote the year. While I used C++ long before that and certainly didn't agree with him, the C++ Linus took issue with was a lot worse than the C++ of today.
- nineteen999 3y ago> makes it out to be. made it out to be. That post is over 15 years old at this point, which goes to the very point of the posted article - C++ has (subjective opinion here) improved a lot in that time. No idea what his current opinion on C++ is. Personally I'd rather there was no C++ or Rust in the Linux kernel. IMHO it would be significantly less of a cognitive burden to convert the entire kernel gradually to C++ than Rust. But I would necessarily hold a man to opinions he held 15 years ago when the landscape has changed so much in that time. Rust was only born the previous year (2006) and not championed by Mozilla until 2009. Yet here we are and there is support in the official kernel for it anyway, whereas C++? Not so much.
- Night_Thastus 3y agoMea culpa, I did not notice the date stamp. C++ 15 years ago was certainly much worse than today.
- charcircuit 3y agoI'm skeptical that this is better than starting to rewrite the kernel in Rust. It would be better if everyone can focus on rewriting things into Rust rather than having a choice of rewriting into C++ or Rust. Unlike this email, C can be converted into Rust piecemeal and integrate with the rest of the kernel. It's also in kernel developers best interest to start learning Rust, and getting them to start earlier than later will be beneficial.
- kyrofa 3y ago> Unlike this email, C can be converted into Rust piecemeal and integrate with the rest of the kernel. Did you read the entire email? Here's a quote that seems to directly contradict you: > converting C code to Rust isn't something that can be done piecemeal, whereas with some cleanups the existing C code can be compiled as C++. As far as I can tell, the author is correct. What is the pattern for converting C to Rust piecemeal?
- charcircuit 3y ago>What is the pattern for converting C to Rust piecemeal? You take a piece and either rewrite it yourself or use a transpiler that produces potentially unsafe Rust code which you then later would want to rewrite into safe Rust code.
- steveklabnik 3y agoA recent practical example of the former: the fish shell re-wrote incrementally from C++ to Rust, and is almost finished https://github.com/fish-shell/fish-shell/discussions/10123 https://github.com/fish-shell/fish-shell/discussions/10123 An example of the latter: c2rust, which is a work in progress but is very impressive https://github.com/immunant/c2rust https://github.com/immunant/c2rust It currently translates into unsafe Rust, but the strategy is to separate the "compile C to unsafe Rust" steps and the "compile unsafe Rust to safe Rust" steps. As I see it, as it makes the overall task simpler, allows for more user freedom, and makes the latter potentially useful even for non-transpiled code. https://immunant.com/blog/2023/03/lifting/ https://immunant.com/blog/2023/03/lifting/
- loup-vaillant 3y ago> We do a lot of metaprogramming in the Linux kernel, implemented with some often truly hideous macro hacks. If you do a lot of meta-programming… why not used a more principled approach like Lex & Yacc? Why not go all the way to design mini-languages and compile them to C? Or design C extensions and compile them to C? You can still have good debugging support with line markers. https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
- bjourne 3y agoYou'd just be reinventing C++.
- Turing_Machine 3y agoI sure hope not.
- jraph 3y agoNo reply from Linus Torvalds yet! Hoping to find one was half the reason why I clicked on this.
- kwant_kiddo 3y agoSomewhat related: In 2020 gcc bumped the requirement for bootstrapping to be a C++11 compiler [0]. Would have been fun to see the kernel finally adopt C++14 as the author suggested. I don't think that Linus will allow this since he just commented that he will allow rust in drivers and major subsystems [1]. would have hoped see more answers or see something in here from actual kernel developers. 0: https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe20... 1: https://youtu.be/YyRVOGxRKLg?si=_ad7wU51bDdDg6Ic&t=104 https://youtu.be/YyRVOGxRKLg?si=_ad7wU51bDdDg6Ic&t=104
- crq-yml 3y agoThe path to migrate to Zig is, or would be, the most straightforward, except that that language is not ready. But in design terms it's definitely got the things the OP is championing C++ for, and a better story for actually addressing longstanding systems programming issues instead of heaping stuff onto the C toolchain and therefore making everyone debug C build-time errors.
- TwentyPosts 3y agoSeeing that the last time I tried to use Zig–completely inexperienced, trying to do completely basic stuff–I hit a compiler bug within two hours, I'd say that "not ready" is about right. To be fair, the latest Github version had the bug already fixed, but it's still a sign the language is basically still in an alpha stage.
- binary132 3y agoI think the standard library has some bugs too.
- LorenDB 3y agoThe reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and...) syntax. Don't get me wrong, I like the concept of memory safety, but I think too many languages are going "We have to stand out!" and therefore are creating completely new syntaxes. That may work for you, but frankly, I'm happiest in a language that sticks close to C++ syntax (which is probably one reason I love D so much). Also, C build errors have nothing to do with C++? What are you getting at there?
- j-james 3y agoI'd be a little interested to hear what you like about C++'s syntax! As a non-C++ programmer, I mostly think of the language as a pile of mistakes that kinda had to happen for other languages to learn from them, very much including syntax (ex. types preceding declarations, necessitating `auto` and complicating parsing) - and I actually think the ugliest parts of Rust copy those mistakes (ex. using <> for generics, which are ambiguous with less-than greater-than when used with no whitespace, necessitating the turbofish). (I've heard plenty of complains about Rust syntax, so I'm less so interested in that than what C++ syntax gets right. Unless it's just a familiarity thing...)
- xorcist 3y agoAs with all good writing, it is hard for me to tell serious suggestions from satire. However, hpa seems to be the crazy genius type, so maybe it's all for real. The thing I'd like to know is, given that the kernel is written in "kernel C", a shared culture about how C should be used together with a hairy mountain of macros, why not make kernel-C a proper language? It's probably just a number of extensions away. Together with some rules about code generation, it could make for a fairly neat dialect of C that would be much easier to use and understand. It would also pave the way for further experiments with compile time guarantees about soundness of isolated sections of the code. Because, and we should be honest about this, going any C++-like route would impact the long term quality of submitted code. There should be no technical reason for this, but that does not make it something that should be turned a blind eye on.
- bfrog 3y agoWhat’s the benefit? Rust actually is a nice language. C++ requires deciding which features to use? I don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large projects move forward.
- foofie 3y ago> Rust actually is a nice language. C++ requires deciding which features to use? With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example. > don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding. Indeed you don't know what you're talking about. Adopting a style guide is not the same thing as joining a cult. C++ has been in active use for around 30 years, and modern C++ for over a decade. People use it just fine, and don't feel the need to evangelize. Other communities sadly still appear to feel a constant need to reassure and convince themselves they didn't made the wrong choice.
- bfrog 3y agoShould I use boost style? Qt/Eigen styling? Can I get a subset of the language and stdlib without allocations? Should I use multiple inheritance with I classes or template duck typing? What’s the cycle and storage cost of smart pointer wrappers? Atomics kill pipelines and caches. Yeah the zero cost isn’t actually zero cost sorry to say. Are closed over stack variables moved or referenced? If referenced, what happens if the closure outlives the call context?
- binary132 3y agoGoogle style guide is good tbh. You should use the right tool for the job. std::unique_ptr is just a move-only ergonomics type over a bare pointer, it doesn't have extra state. std::shared_ptr is basically no different than Rust's Arc. Closures specify capture semantics explicitly, so you will always know, and default to copy. And yes, you can capture local references and leave. Don't do that, or return references to local variables, or lots of other fun stuff.
- binary132 3y agoKinda feel like he just wrote this to make the rust folks seethe.
- Gow8876 3y agoShould have been titled as Converting the Kernel to Rust. Heck even to Zig would be more appealing.
- neva_krien 3y agodoes this have implications on the place of c in the programming world? I am seeing this trend in HPC and systems programming to move into more structured languages. even FORTRAN has objects now. gives me some doubts if I should put my time into learning c or not. a lot of the tech I care about uses c++ (i want to work in ANNs) and true the kernels are basically in c but the code is c++.
- 6R1M0R4CL3 3y agoperhaps it is possible. modern c++ is quite different from the previous incarnations of c++ but when you are writing kernel code.. you have in a space where a lot of stuff is not available : you are running in the kernel context. the userland part is waiting for you to give control back, so your code must be fast, do the required job, and be predictible. we cannot have a line of code that will, sometimes, create a huge cpu or memory load because a lot of stuff is going to happen behind it. that's why C is so effective... the kernel context is not a place where you can have garbage collection or classes-stuff that will happen when you're supposed to get control back to userland as quickly as possible.