Live data from Hacker News

Converting the Kernel to C++

lore.kernel.org

51–56 of 56 posts

Re: Converting the Kernel to C++

#51

Earlier quoted context omitted.

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" whe…

> 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. This is actually not what you want, because as a rule Safe Rust enforces the use of Rust references which have stricter requirements than C++ references or C/C++/Rust raw pointers, and will otherwise introduce UB. (See the Rustonomicon for a detailed description of those requirements.)…

What you're talking about is what I was referring to as "safe APIs that are lying to you and are actually unsound". I've written more about safety and soundness here: https://jacko.io/safety_and_soundness.html

Re: Converting the Kernel to C++

#52
perhaps 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.

Re: Converting the Kernel to C++

#53

Earlier quoted context omitted.

> 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. This is actually not what you want, because as a rule Safe Rust enforces the use of Rust references which have stricter requirements than C++ references or C/C++/Rust raw pointers, and will otherwise introduce UB. (See the Rustonomicon for a detailed description of those requirements.)…

What you're talking about is what I was referring to as "safe APIs that are lying to you and are actually unsound". I've written more about safety and soundness here: https://jacko.io/safety_and_soundness.html

The issue is that the API is not lying to you; it's just as sound as any other piece of Safe Rust. Rather, the point is that UB can easily occur when Safe Rust is called from an unsafe 'context', such as may occur in ordinary C/C++ code; Safe Rust being sound only implies that the UB can in some sense be 'blamed' on the caller. Nonetheless as a practical matter, fixing the UB can require using "unsafe" functions that will be more general than their Safe counterparts.

Re: Converting the Kernel to C++

#54
post #36
post #30

Earlier quoted context omitted.

The 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..…

I'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…

It's pretty much familiarity. If I'd learned Rust back in the day, I'd probably not want to learn C++ for syntax reasons as well.

One thing I think Rust gets wrong is classes. I absolutely don't understand why you would require a separate `impl` block to provide methods. C++ has a reasonable syntax of providing methods in the class.

Re: Converting the Kernel to C++

#55
post #54
post #36

Earlier quoted context omitted.

I'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…

It's pretty much familiarity. If I'd learned Rust back in the day, I'd probably not want to learn C++ for syntax reasons as well. One thing I think Rust gets wrong is classes. I absolutely don't understand why you would require a separate `impl` block to provide methods. C++ has a reasonable syntax of providing methods in the class.

Well, they're not classes, they're interfaces, and so you can implement multiple interfaces for multiple types, and so you have to implement them separately from the type declaration. There's not too much of a way around that, I think.

Re: Converting the Kernel to C++

#56
does 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++.

Post reply on HN