There are theoretical performance improvements possible by compiler optimizations if the guarantees Rust provides are met. However, the kernel relies on a lot of unsafe code to interoperate with C so I don’t expect that to actually happen, because all of the safety guarantees go out of the window the moment you use that keyword.
Well, it largely removes an attack surface for memory bugs, which is a huge thing. If we’re writing a big driver (see the Rust driver for the Apple GPU) then suddenly waving hands incoherently 90% or more of the driver (depending) is likely to be much more memory safe and stable. As has been demonstrated with that particular driver already.
I was watching the streams and when it compiled Asahi Lina usually only had to deal with logical type errors, not memory issues, it was basically a great showcase for Rust and memory safely. Unsafe is perfectly fine Rust, but it’s a contract where the developer says to the compiler: “I know you can’t guarantee this block is safe, so I’ll keep a special eye on that, peer review more, test, etc. while you keep an eye on all the other code I can’t fit in my head”. In the case of Linux an Unsafe blocks means “we’ll trust the Linux kernel code we connect to, though review it carefully”.
So saying all safety goes out the window is wrong, see it as a vastly reduced potential for memory problems, better error handling and more stable drivers, as demonstrated by the Apple GPU driver.
Rust code calling Rust code definitely brings safety improvements. The problem is that a lot of Rust code also needs to interact with C code (to work with pointers, for example) and that’s where unsafe becomes a requirement, and where the compiler’s optimizations don’t get applied automatically anymore.
Unsafe Rust code in the kernel is as safe as the existing C code because unsafe code is the norm, and that’s why Rust only makes things safer. However, in terms of performance improvements alone, you need to have in-depth knowledge of what abstractions you can or cannot use, and unsafe can make a bunch of easy automatic optimisations stop working.
It just depends on how isolated that part of the kernel is. Unsafe code should be done only in interop, and so it still theoretically has a memory safety benefit over C in that sense.
In terms of how much interop code needs to be written for Rust at this point is another discussion though.
Yes, enhanced security is pretty much the entire pitch of Rust. There wouldn’t be any reason for it to result in performance enhancements, though.
There are theoretical performance improvements possible by compiler optimizations if the guarantees Rust provides are met. However, the kernel relies on a lot of
unsafecode to interoperate with C so I don’t expect that to actually happen, because all of the safety guarantees go out of the window the moment you use that keyword.Not all guarantees are gone, even with unsafe
Well, it largely removes an attack surface for memory bugs, which is a huge thing. If we’re writing a big driver (see the Rust driver for the Apple GPU) then suddenly waving hands incoherently 90% or more of the driver (depending) is likely to be much more memory safe and stable. As has been demonstrated with that particular driver already.
I was watching the streams and when it compiled Asahi Lina usually only had to deal with logical type errors, not memory issues, it was basically a great showcase for Rust and memory safely. Unsafe is perfectly fine Rust, but it’s a contract where the developer says to the compiler: “I know you can’t guarantee this block is safe, so I’ll keep a special eye on that, peer review more, test, etc. while you keep an eye on all the other code I can’t fit in my head”. In the case of Linux an Unsafe blocks means “we’ll trust the Linux kernel code we connect to, though review it carefully”.
So saying all safety goes out the window is wrong, see it as a vastly reduced potential for memory problems, better error handling and more stable drivers, as demonstrated by the Apple GPU driver.
Rust code calling Rust code definitely brings safety improvements. The problem is that a lot of Rust code also needs to interact with C code (to work with pointers, for example) and that’s where
unsafebecomes a requirement, and where the compiler’s optimizations don’t get applied automatically anymore.Unsafe Rust code in the kernel is as safe as the existing C code because unsafe code is the norm, and that’s why Rust only makes things safer. However, in terms of performance improvements alone, you need to have in-depth knowledge of what abstractions you can or cannot use, and
unsafecan make a bunch of easy automatic optimisations stop working.It just depends on how isolated that part of the kernel is. Unsafe code should be done only in interop, and so it still theoretically has a memory safety benefit over C in that sense.
In terms of how much interop code needs to be written for Rust at this point is another discussion though.