4 ms·
I suspect it's more of a 'this would be handy to have, and I would prefer to use rust' as opposed to motivated by making the language harder to do without in th
by rcxdude 1y ago
I suspect it's more of a 'this would be handy to have, and I would prefer to use rust' as opposed to motivated by making the language harder to do without in the kernel. Certainly this kind of thing I would find rust much nicer for than C.
(I would agree the first argument is kinda wavy. If anything the panic handler has a fairly unique relationship with memory safety: it's likely to be executing in an environment where that's already gone out the window and it needs to try to assume as little as possible about what might or might not be correct that its reading from and writing to, while also its own memory safety is perhaps less critical because the system is already crashing, it's just got to get the info out before everything completely stops. Though that doesn't make it immune from security concerns. A code execution vulnerability in the handler means any panic could turn into a worse problem)
- tialaramex 1y agoThe elaborate Rust type system and so on does not exist in the machine code executing when "the system is already crashing". Very often it turns out that expressive Rust you wrote which talks about a fancy Iterator protocol and a lambda function just got compiled into the same sixteen CPU instructions that would have been emitted for the (much harder to understand) macro expanded C you'd have to write instead with the same meaning. Rust vs C matters a lot more for maintainers, who read the source code - hopefully not from a machine which is currently crashing - than for the executable kernel itself.
- rcxdude 1y agoI'm aware, whuch means that e.g. you're liekly already in undefined behaviour land and rust's safety guarantees are no longer, well, guaranteed.