Supporting Linux kernel development in Rust
Supporting Linux kernel development in Rust
Posted Sep 4, 2020 7:04 UTC (Fri) by vegard (subscriber, #52330)In reply to: Supporting Linux kernel development in Rust by geofft
Parent article: Supporting Linux kernel development in Rust
What you say sounds "easy" in a way, but is it really possible at all in most cases?
The Linux kernel is notorious for its use of intrusive doubly-linked lists, and Rust is notorious for the difficulty/discouragement of linked lists. Surely if it was just a matter of finding a safe abstraction in Rust (i.e. wrapper around unsafe code), Rust would also have easy-to-use linked lists?
If I remember correctly, whenever you have two pieces of unsafe code that individually present a "safe" interface, there is a possibility of an interaction that makes the combination unsafe, most famously <https://github.com/rust-lang/rust/issues/24292>. A whole bunch of people have worked on proving that all these safe abstractions are safe in the presence of each other (i.e. the RustBelt project). Wouldn't we need a whole bunch of verification work to make this work for the kernel?
Posted Sep 4, 2020 8:45 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Rust has a standard library linked list, and the abstractions for instrusive double-linked list and intrusive single-linked list have been written.
The reason linked lists are discouraged in Rust apply to C and assembly, too - they are fundamentally all about pointer chasing, and that's the hardest thing for a CPU to perform well at; other data structures are normally what you want, but the emphasis on linked lists in formal education (and in languages with "sufficiently smart" compilers like Haskell) means that people reach for them when they're the wrong choice.
Posted Sep 4, 2020 9:30 UTC (Fri)
by roc (subscriber, #30627)
[Link]
The problem in the issue you linked to was JoinGuard assuming safe Rust doesn't leak. In fact, safe Rust is allowed to leak. So this problem wasn't due to an interaction between unsafe code modules, but because one piece of unsafe code assumed a property of safe Rust code that doesn't necessarily hold.
This was an understandable mistake in 2015 because then there wasn't as clear a picture of what the invariants around safe Rust actually are. The picture is clearer now, although still not fully clear. So maybe in the future some invariants will be clarified that invalidate the assumptions made by some unsafe code --- but even then, there is no general problem of "the possibility of an interaction that makes the combination unsafe".
Supporting Linux kernel development in Rust
Supporting Linux kernel development in Rust