[HN Gopher] Converting the Kernel to C++
___________________________________________________________________
Converting the Kernel to C++
Author : artagnon
Score : 50 points
Date : 2024-01-10 14:58 UTC (8 hours ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| TwentyPosts wrote:
| Please, 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 wrote:
| Using 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 wrote:
| Are you referring to a specific subset of C++?
| synergy20 wrote:
| There 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 wrote:
| Old but gold https://harmful.cat-v.org/software/c++/linus
| Night_Thastus wrote:
| EDIT: 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 wrote:
| Note 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 wrote:
| > 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 wrote:
| Mea culpa, I did not notice the date stamp. C++ 15 years
| ago was certainly much worse than today.
| charcircuit wrote:
| I'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 wrote:
| > 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 wrote:
| >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 wrote:
| A 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
|
| An example of the latter: c2rust, which is a work in
| progress but is very impressive
| 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/
| zerd wrote:
| > What is the pattern for converting C to Rust piecemeal?
|
| You can call Rust from C, and C from rust. You can convert it
| function by function.
| qsdf38100 wrote:
| Won't you end up with mostly _unsafe_ code this way?
| steveklabnik wrote:
| It is true that the boundary will be unsafe, and that's
| more than if it were to be all in pure Rust, but that
| does not change that, even when doing kernel level work,
| in practice it has generally been shown that unsafe code
| is still relatively small in amount.
| oconnor663 wrote:
| It really depends. If the interface that you're wrapping
| can have a nice, abstract API (like "parse this JPEG
| header into a struct" or something), then the hope is
| that you can figure out how to express that API in safe
| Rust, even though underneath it might be a big pile of C.
| The trouble is when there is no clean API boundary that
| can fit within safe Rust's rules, like when the
| underlying C code is "object soup" where everything has
| pointers to everything else, and it's all up to the
| programmer to know when it's safe to free things. In that
| case trying to wrap all that in Rust either gives you
| unsafe code everywhere, or maybe worse, "safe" APIs that
| are lying to you and are actually unsound.
| p0w3n3d wrote:
| I hope I am wrong, but this sounds as if the guy wrote the
| email thought that C is a subset of C++.
|
| No it is not. First example: initialisation of structs
| anordal wrote:
| I'm skeptical because C++ is a slippery slope. Glad to see they
| are going for templates and concepts, and not constructors and
| destructors.
|
| Yes, what C++ is supposedly good for - RAII, it actually got a
| little wrong:
|
| 1. Default construction / value initialization: Causes lots of
| initialization before assignment that is obviously unnecessary.
| Try allocating a buffer: `std::make_unique<char[]>`
| surprisingly memsets the buffer.
|
| 2. Constructors: No way to fail without exceptions. That buffer
| example again: Without exceptions, `std::make_unique<char[]>`
| will actually attempt to memset a nullptr on allocation failure
| ... before your nullptr check (which btw makes the compiler
| entitled to delete your nullptr check as well).
|
| 3. Move is a (burdensome) runtime state that mandates
| nullability.
|
| 4. Destructors: Can't take arguments, forcing objects to
| contain implicit references to each other.
|
| Rust's affine type system fixes 1-3, but not 4, which only a
| linear type system could:
| https://en.wikipedia.org/wiki/Substructural_type_system#The_...
| janice1999 wrote:
| > I'm skeptical that this is better than starting to rewrite
| the kernel in Rust.
|
| I recently migrated a complex cross platform C99 embedded
| project to C++17. We got the build systems ported in a day and
| are able to chip away at it piece by piece.
|
| We looked at Rust but the main issue wasn't technical it was
| the large learning curve for the team. Rust is not as intuitive
| to C developers are C++ is.
| loup-vaillant wrote:
| > _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
| jraph wrote:
| No reply from Linus Torvalds yet! Hoping to find one was half the
| reason why I clicked on this.
| kwant_kiddo wrote:
| Somewhat 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/5329b59a2e13dabbe20...
|
| 1: https://youtu.be/YyRVOGxRKLg?si=_ad7wU51bDdDg6Ic&t=104
| crq-yml wrote:
| The 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.
___________________________________________________________________
(page generated 2024-01-10 23:01 UTC)