Linux kernel driver layers can have rather complicated nested structures. Some are a hybrid of of two subsystems like USB and ALSA (audio). Both have smaller structures inside them per each subsystems. In the case of a class compliant USB audio driver, both subsystems 1/
Conversation
are combined into one structure. They then have to share references in the code across subsystem which, from my picture of modern type systems, can be really complicated if it's in the form of type inheritance. Maybe i'm misunderstanding you here but that's my internal picture 2/
1
Rust can represent complex data structures and doesn't lose safety in normal Rust code. Arc<Mutex<T>> is a very flexible building block for mutable data structures shared across threads. Arc and Rc support weak pointers too, and you can get references to the contents.
1
1
The way that Mutex<T> works is that you call the method to obtain the lock, and it gives you a mutable reference that the compiler prevents from outliving the lock scope. It simply uses the existing language features, just like the collections / iterators. It's pure library code.
1
1
RefCell<T> is pretty much the same thing for single-threaded cases, if you need dynamic mutable references for something that cannot be represented via the usual static aliasing checks. It's usually not needed as the rules for static checks can represent a lot of patterns.
1
1
You're usually just using data owned by local variables, moving ownership around and passing around references tied to the lifetimes of those local variables. Types like Rc<T> and RefCell<T> are a safe escape hatch for complex patterns but in idiomatic code they're pretty sparse.
1
1
And even if you're using Rc<T>, you'll mostly be using very few Rc<T> owners that you pass around by moving ownership along with lots of lightweight references into the data, which the compiler guarantees do not outlive the reference counted pointer type they were derived from.
1
The whole point of Rust is building these lightweight safe abstractions, via a basic set of rules for ownership, moving ownership and borrowing immutable / mutable references. In a kernel, you do need unsafe {} blocks / functions, but you build safe abstractions around them.
2
1
Yeah if I'm understanding you correctly you're basically annotating away bits if they're difficult to analyze with unsafe blocked right ? If so, I think that's a good work around for now. The only caveat that I can think of is a scenario where a the language extension 1/
2
Normal Rust code is verified to be memory / type / thread-safe and the implementations of the low-level building blocks like Vec<T> (like std::vector in C++) use unsafe code that's part of the trusted computing base with the compiler. Most things are really library features.
1
The unsafe blocks / functions are used for low-level code, like FFI into a C library, inline assembly, or working directly at a low level with hardware. They're responsible for their own safety, just like C, but they're used to build safe APIs for use elsewhere.
Trying to figure out how to ask this. So I have another question. What's the view of your technical community regarding kernel performance ? Specifically concurrency. Is it a thread pool model ? What about lockless data structures ?
1
The Rust community is obsessed with absolute performance, and there are many lock-free data structures (albeit lock-free is often slower than a mutex).
Concurrency isn't really specific to kernels. The core team is working on making futures and async/await official soon.