2 ms·
I think the problem lies with the fact that you cannot write kernel code without relying on unsafe blocks of code. So arguably both camps are correct. Those wh
by hnlmorg 11mo ago
I think the problem lies with the fact that you cannot write kernel code without relying on unsafe blocks of code.
So arguably both camps are correct. Those who advocate Rust rewrites, and those who are against it too.
- ViewTrick1002 11mo agoYou can’t write rust code without relying on unsafe code. Much of the standard library contains unsafe, which they have in parts taken the time to formally verify. I would presume the ratio of safe to unsafe code leads to less unsafe code being written over time as the full ”kernel standard library” gets built out allowing all other parts to replace their hand rolled implementations with the standard one.
- jeroenhd 11mo agoI don't think this code needed to be unsafe. This code doesn't involve any I/O or kernel pointer/CPU register management; it's just modifying a list. I'm sure the people who wrote this code had their reasons to write the code like this (probably simplicity or performance), but this type of kernel code could be done safely.
- aw1621107 11mo agoAs pointed out by yuriks [0], it seems the patch authors are interested in looking into a safer solution [1]: > The previous patches in this series illustrate why the List::remove method is really dangerous. I think the real takeaway here is to replace the linked lists with a different data structure without this unsafe footgun, but for now we fix the bugs and add a warning to the docs. [0]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357 [1]: https://news.ycombinator.com/item?id=46307357 https://news.ycombinator.com/item?id=46307357