Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "what is wrong with rust and linux????" video.

Asahi Lina wrote a thread on X 2023-08-31 about Linux kernel APIs being too inaccurate and how it affected her GPU driver which is written in Rust. Her driver could support runtime loading and unloading but the kernel C level APIs have way too many edge cases undefined and when she contacted the authors of C level API she received "just copy what amdgpu driver is doing" instead of having a clear definitions of the expected behavior. And it turns out that the amdgpu driver doesn't even do the thing she was asking about! Update: I see you reviewed part of this thing near 50:00.
2
@sophiophile Btrfs has lots of great features but the runtime performance compared to ext4 and XFS has been too big a sacrifice to make it a bit hard choice. Yes, you cannot have all those features with zero overhead but the overhead has been too great historically.
2
@RobBCactive I've understood that Rust developers want known decisions when stuff changes. They are okay with interfaces changing but those changes must be intentional, not accidental. Currently the C developers seem to be thinking that they can avoid saying what the intent actually is and whatever is implemented is now spec instead. That is, any buggy behavior is part of the spec and if the buggy behavior is fixed, that's the new spec.
2
@sophiophile Good points! I typically consider filesystem performance assuming cold cache because that's the situation where you get the worst latency and the filesystem architecture matters the most. If you have small enough amount of data that it can fit in caches, Btrfs is definitely a good option. Btrfs can also handle RAID1 setups with mixed sized devices even better than mdadm or ZFS, especially when you're extending existing array with new devices.
1
@RobBCactive Sure, the only way in long run is to have accurate API definition in machine readable form. Currently if you use the C API, you "just have to know" that it's your responsibility to do X and Y if you ever call function Z. Unless we have machine readable definition (be it in Rust or any other markup) there's no way to automate the verification that the code is written correctly. It seems pretty clear that many kernel developers have taken the stance that they will not accept machine readable definitions in Rust syntax. If so, they need to be willing to have the required definitions with at least some syntax. As things currently stand, there are no definitions for lots of stuff and other developers are left guessing if a given part of the existing implementation is "the specification" or just a bug. If C developers actually want that the C implementation is literally the specification, that is, the bugs are part of the current specification, too, they just need to say that aloud. Then we can discuss if that idea is worth keeping in long run. Note that if we had machine readable specification in whatever syntax, the C API and Rust API could be automatically generated from that specification. If that couldn't be done then that specification is not accurate enough. (And note that such specification would only define the API, not the implementation. But such API definition would need to define responsibilities about doing X or Y after calling Z which C syntax cannot do.)
1
@RobBCactive Do you agree that if we have a function like iget_locked() and after calling that function you MUST do something with the data or the kernel will enter in corrupted state, this behavior is part of the kernel API? Now, do you agree that C cannot represent this requirement? If you agree both previous points, then you must also agree that there cannot be even in theory a compiler that can catch a programming error where the programmers fails to follow this API (assuming we only have C code as machine readable input data). Rust people are trying to say that quality of the kernel would improve if we had a compiler that can catch errors of this kind. And Rust compiler can already do this if you encode the API information in Rust syntax using types to represent the API behavior. And it seems that Linus agrees and that's why Rust was accepted into kernel despite the fact that the Rust syntax has much higher learning curve than C. The C developers that want to downplay Rust are basically arguing that either (1) there's no need to catch programming errors automatically, or (2) having to write the exact requirements would be too expensive so it's not worth the effort. Which camp do you belong to? I'm personally definitely against (1) because I see kernel level security vulnerabilities and driver crashes way too often. And about (2) I'm not that sure. I think it's worth the effort to try it to improve the quality of the kernel. And the reason to try to use it for filesystem interfaces is because the filesystems are so critical for data safety. If your GPU crashes every now and then, that's non-optimal. If your filesystem randomly corrupts data when threads access the shared data incorrectly or some piece of code does double free, that's a really bad day and hopefully you had backups.
1
19:10 Open source developers also feel any comments about their code as personal attack. When someone starts to react to feeling of personal attack over the actual code and automation, you'll end up with bloody fights. And that was demonstrated here by the filesystem maintainer that really wants to use C only and totally ignore Rust. I guess he really assumed that he must learn Rust and maintain these Rust bindings in the future and he's aggressively trying to avoid that future right now.
1