As a language, it fully supports it. It fits well into the idiomatic error handling system based on sum types (typically Result) including syntactic sugar for bubbling up the errors.
Unlike C++, no-unwind support is standard, but high level stdlib mostly relies on panic on OOM.
Conversation
The high level stdlib has no relevance to the kernel usage because it MUST use $![no_std] (freestanding) code. The high-level stdlib (libstd) uses lower-level standard libraries (libcore, liballoc, etc.) and they can use some of those, but they will need a stripped down liballoc.
1
So, basically, the only issue is they haven't yet forked liballoc to delete the methods doing panic on OOM. It's the same reason they need other placeholder stubs doing panic to fill in APIs used by stdlib code they've included via libcore, etc. Could fork libcore and delete it.
2
I don't know about the practicality of having to fork and maintain a likely incompatible version of rust, just for the Linux kernel.
2
Last time I checked you don't need a special C compiler for the Kernel, C is basically assembler with Macros.
2
They use a very extended version of C supported by GCC/Clang and they use their own memory model not truly implemented by GCC/Clang rather than the C11 memory model. They don't use the C standard library.
For Rust, they don't need a special dialect of the language in the kernel.
1
They do need their own version of the higher level standard libraries (at most they can use libcore), but for C, they can't use the standard library at all.
Rust has standardized equivalents to most of the GCC/Clang extensions they use. Standard C doesn't even have inline asm.
1
It's fairly easy to start using Rust. However, the whole point of using Rust is having most of the code in the safe dialect. In order to do that, you need substantial work making safe APIs that don't need to be marked as unsafe functions in Rust. That's most of the work.
1
You can directly call all the C functions from Rust, but C functions are mostly unsafe APIs. You have to wrap them into safe APIs. You *cannot* use C macros from Rust, but you can redo them. That's a small amount of the work. Most will be designing/implementing safe APIs.
1
You *could* use Rust to directly call the C functions and write code that's as low-level as the C code. It can do the same stuff as C. The point is containing that dialect to a small subset (like 5% of overall code) and the vast majority can avoid using unsafe blocks/functions.
So, they need to make a shared infrastructure wrapping unsafe, low-level concepts used in the kernel into safe APIs, and then that can be reused to write millions of lines of code in the safe dialect for drivers, etc.
1
Unsafe blocks / functions are there as an escape hatch, but writing good Rust means coming up with safe APIs mapping the safety rules to the type system (ownership / destructors, reference lifetimes, sum types, traits, etc.).
It will probably help improve kernel C APIs too.
1
Show replies