4 ms·
> I don't see why it's so important to rewrite parts of the kernel in rust, It'd be nice to be able to say, "We're pretty sure these source code files don't co
by elihu 2y ago
> I don't see why it's so important to rewrite parts of the kernel in rust,
It'd be nice to be able to say, "We're pretty sure these source code files don't contain any null pointer dereferences, array out-of-bounds errors, use-after-free errors, double frees, or (if the kernel rust project fully embraces the Rust way of doing concurrency, I'm not familiar with the technical details) race conditions, because otherwise it wouldn't have compiled." When absolutely necessary, unsafe code blocks can provide a back door around some of these checks, but as long as the unsafe code blocks are relatively small, it's a much smaller surface area for these kinds of bugs to show up.
Not to mention the type system is in some ways much more user friendly. Proper algebraic types are easier than trying to cobble something ad-hoc together with tagged unions.
> or why Drew is so sympathetic to the cause.
He's not, he's suggesting in the most polite and diplomatic way possible that he thinks they should stop what they're doing, and do something else instead that kernel maintainers don't have to deal with.
- EE84M3i 2y agoSafe rust cannot guarantee the lack of race conditions, only the lack of data races.
- elihu 2y agoA fair point. You could have two simultaneous code paths access the same hardware device, if such were not protected by a lock or some form of exclusive access to some associated data structure.