C++ devs are spinning in their graves now.
The kernel is mostly C code, not C++.
Hence the previous comment. If Linux was (partially) written in C++, it would no longer work.
Rust in the kernel is no longer experimental
651–660 of 853 posts
Re: Rust in the kernel is no longer experimental
#652Earlier quoted context omitted.
it is not straightforward in rust because the linked list is inherently tricky to implement correctly. Rust makes that very apparent (and, yeah, a bit too apparent). I know, a linked list is not exactly super complex and rust makes that a bit tough. But the realisation one must have is this: building a linked list will break some key assumptions about memory safety, so trying to force that into rust is just not gonna…
Can you elaborate, what key assumptions about memory safety linked lists break? Sure, double linked lists may have non-trivial ownership, but that doesn't compromise safety.
Rust wants all memory to be modeled as an ownership tree: the same bit of memory can't be owned by more than one data structure. A doubly linked list breaks that requirement so it can't be modeled in safe Rust directly. The options are using unsafe, or using one of the pointer wrapper types that have runtime checks that ensure correct behavior and own the underlying memory as far Rust is concerned.
Re: Rust in the kernel is no longer experimental
#653Earlier quoted context omitted.
https://www.phoronix.com/news/Alex-Gaynor-Rust-Maintainer >
"Yay, we got Rust in the Kernel! ^_^ Ok, now it's your code! Bye!"
1. He left before Rust stopped being experimental.
2. Maintainers come and go all the time, this is how open source works.
3. The only reason Phoronix reports on this is because anytime they mention Rust it attracts rage bait clicks, for example, your comment.
Re: Rust in the kernel is no longer experimental
#654Earlier quoted context omitted.
C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…
> that C can express that Rust cannot The reverse is probably more true, though. Rust has native SIMD support for example, while in standard C there is no way to express that. 'C is not a low-level language' is a great blog post about the topic.
> Rust has native SIMD support
std::simd is nightly only.
> while in standard C there is no way to express that.
In ISO Standard C(++) there's no SIMD.
But in practice C vector extensions are available in Clang and GCC which are very similar to Rust std::simd (can use normal arithmetic operations).
Unless you're talking about CPU specific intrinsics, which are available to in both languages (core::arch intrinsics vs. xmmintrin.h) in all big compilers.
Re: Rust in the kernel is no longer experimental
#655Earlier quoted context omitted.
Can you elaborate, what key assumptions about memory safety linked lists break? Sure, double linked lists may have non-trivial ownership, but that doesn't compromise safety.
Rust wants all memory to be modeled as an ownership tree: the same bit of memory can't be owned by more than one data structure. A doubly linked list breaks that requirement so it can't be modeled in safe Rust directly. The options are using unsafe, or using one of the pointer wrapper types that have runtime checks that ensure correct behavior and own the underlying memory as far Rust is concerned.
You can do it by combining ghostcell/qcell along with some bespoke "static/compile-time reference counting" for the double links part. But ghostcell/qcell is quite difficult to use with Rust's current feature set (it has to use lifetime hacks to place a safe "brand" on type instantiations, a kind of quasi-capability construct), so it hasn't become a part of standard rust so far.
Re: Rust in the kernel is no longer experimental
#656Earlier quoted context omitted.
Which ones would that be?
In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…
You probably shouldn't include Rust's Tier 3 in this list. If you have to, at least make it separate.
Re: Rust in the kernel is no longer experimental
#657Earlier quoted context omitted.
It's great that the Google Android team has been tracking data to answer that question for years now and their conclusion is: ------- The primary security concern regarding Rust generally centers on the approximately 4% of code written within unsafe{} blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that unsafe Rust might be more buggy than C. Empirical evidence shows…
> The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.
It does, if you read the report and run a little (implied) math.
The report says that their historical data gives them an estimate of 1000 Memory Safety issues per Million Lines of Code for C/C++.
The same team currently has 5 Million lines of Rust code, of which 4% are unsafe (200 000). Assuming that unsafe Rust is on par with C/C++, this gives us an expected value of about 200 memory safety issues in the unsafe code. They have one. Either they have 199 hidden and undetected memory safety issues, or the conclusion is that even unsafe Rust is orders of magnitude better than C/C++ when it comes to memory safety.
I trust them to track these numbers diligently. This is a seasoned team building foundational low level software. We can safely assume that the Android team is better than the average C/C++ programmer (and likely also than the average Rust programmer), so the numbers should generalize fairly well.
Part of the benefits of Rust is indeed that it allows local reasoning about crucial parts of the code. This does allow for higher scrutiny which will find more bugs, but that's a result of the language design. unsafe {} was designed with that im mind - this is not a random emergent property.
Re: Rust in the kernel is no longer experimental
#658Earlier quoted context omitted.
> Functions like that can and should be marked unsafe in rust. That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.
It is how it's supposed to work. `unsafe` is intended to be used on functions where the caller must uphold some precondition(s) in order to not invoke UB, even if the keyword is not strictly required to get the code to compile. The general rule of thumb is that safe code must not be able to invoke UB.
Yes. I was objecting to the parent poster's "can and should be" which sounds like they think people just randomly choose where to use the unsafe decoration.
Re: Rust in the kernel is no longer experimental
#659Earlier quoted context omitted.
That's a library feature (not intended for release builds), not a language feature.
It is intended for release builds. The ReleaseSafe target will keep the checks. ReleaseFast and ReleaseSmall will remove the checks, but those aren't the recommended release modes for general software. Only for when performance or size are critical.
DebugAllocator essentially becomes a no-op wrapper when you use those targets.