3 ms·
I feel like everyone involved in the Linux Kernel Rust world is ironically woefully unaware of how Rust actually works, and what it's actually capable of. I sus
by phendrenad2 11mo ago
I feel like everyone involved in the Linux Kernel Rust world is ironically woefully unaware of how Rust actually works, and what it's actually capable of. I suspect that Rust gurus agree with me, but don't want to say anything because it would hurt Rust adoption in places where it actually is helpful (encryption algorithms...)
Kernels - and especially the Linux kernel - are high-performance systems that require lots of shared mutable state. Every driver is a glorified while loop waiting for an IRQ so it can copy a chunk of data from one shared mutable buffer to another shared mutable buffer. So there will need to be some level of unsafe in the code.
There's a fallacy that if 95% of the code is safe, and 5% is unsafe, then that code is only 5% as likely to contain memory errors as a comparable C program. But, to reiterate what another commenter said, and something I've predicted for a long time, the tendency for the "unsafe block" to become instrumented by the "safe block" will always exist. People will loosen the API contract between the "safe" and "unsafe" sides until an error in the "safe" side kicks off an error in the "unsafe" side.
- bronson 11mo ago> Every driver is a glorified while loop waiting for an IRQ This is so obviously false that I suspect there's the reason you don't see any Rust gurus agreeing with you. Drivers do lots of resource and memory management, far more than just spinning on IRQs.
- infamouscow 11mo agoI should probably ask what experience do you have writing hardware drivers for the Linux kernel, but it's pretty obvious the answer is: none. I actually burst out laughing reading your comment, it's ridiculous. My anecdotal experience interviewing big tech engineers that used Rust reflects GP's hunch about this astonishing experience gap. Just this year, 4/4 candidates I interviewed couldn't give me the correct answer for what two bytes in base 2 represented in base 10. Not a single candidate asked me about the endianness of the system. Now that Rust in the kernel doesn't have an "experimental" escape hatch, these motte-and-bailey arguments aren't going to work. Ultimately, I think this is a good thing for Rust in the kernel. Once all of the idiots and buffoons have been sufficiently derided and ousted from public discourse (deservedly so), we can finally begin having serious and productive technical discussions about how to make C and Rust interoperate in the kernel.
- bronson 11mo agoYou're saying you believe every Linux driver actually is a glorified while loop? I guess it makes sense you're having trouble hiring qualified candidates.
- deleted 11mo ago[deleted]
- quotemstr 11mo agoHe's arguing most drivers are mostly event driven --- which is true, trivially.
- bronson 10mo agoThat's remarkable, since his comment says nothing about events. Still, it sounds like you're saying that Linux drivers are more than glorified do loops spinning on IRQs, right? If so, then I guess we agree.
- jibal 10mo agoNowhere did he argue that. What he actually argued--poorly and offensively--is that it's "pretty obvious" that bronson has no experience writing Linux hardware drivers.
- emil-lp 11mo agoWhen you say "base 10", is that "10"-er written in big endian or small endian? It's as if there's a convention of sorts to how we write numbers (regardless of base). If you don't state endianness in your exercise, one should assume the convention is followed.
- jibal 10mo agoThat makes no sense. The value of two bytes as a single number is strictly dependent on endianness, and there's no "convention" that can be assumed.
- phendrenad2 10mo agoI'll accept praising with faint disagreement any day.