Im not really following kernel dev much, but I am a C and C++ programmer. Has the Rust panic() issue been resolved?
Does the lack of a standard, or even specification (code isn't a specification), not put a stop to this? I would expect a language in the kernel I run to at least have a stable specification or standard. I might be the old man screaming at the cloud.
The C bits of the kernel aren't even written closely to any C specification - they are written to, essentially, "what gcc does and is likely to keep doing". They also use a number of gcc extensions which are underspecified compared to C itself.
I'm not sure this is a real concern for the Linux kernel devs.
IIRC there was only a concern around allocation but the rust std is moving to fallible allocations for that reason (and the rust integration seems to ship their own std lib anyway)
Otherwise there is no issue in redefining panic() to call the kernel oops handler and have the kernel perform a coredump.
Yeah, that has become largely a non-issue, all the alloc structure allow for fallible allocation now via a separated function call (and the old ones simply use the new one with an unwrap() call to panic on error).
Rust is entirely fine working with custom allocation stuff, there isn't any hidden allocator calls in you can make (well, the box operator, but that has been nightly forever and likely won't appear outside the stdlib ever).
The box operator is basically how Box::new operates. One of the big problems if you were to DIY it, is to prevent stack allocation of heap data. The naive approach will result in your data first having to be allocated on the stack, passed to Box::new and then moved into the heap.
The box operator allows moving the initialization of a datastructure into the heap entirely (and the compiler also auto-insert the malloc calls).
It is largely a one-trick pony that only exists to help out the standard library, nobody should be using it ever. But it is the one instance where the rust compiler will deploy an allocation on the heap without any obvious way to tell that it did that.
> I would expect a language in the kernel I run to at least have a stable specification or standard.
I hear this occasionally, and I guess I'd like to better understand it. If a document existed that was called "The Rust Specification", why/how would that be significant for kernel development?
If there is a specification, one can write code for a version of that specification, and later down the line someone can build a compiler for it according to the specification - youre implementation-independent. Seems important to me.
Maybe I'm dense, but why is this necessary, or specifically helpful, re: kernel development? As I understand it, the Linux kernel doesn't assiduously follow the C spec (it uses many GNU specific extensions). And C spec itself is often not fully implemented on many platforms (see C11 Annex K). If the answer is "It could break", well, Rust probably does more to prevent breakage than any language I know. Definitely more than the C spec ever has.
Would it be nice for the devs to take an extended holiday to write a mind-numbing technical document for the benefit of 2-3 teams working on alternative compilers? Maybe? But, also, maybe not.
17 comments
[ 4.2 ms ] story [ 51.5 ms ] threadDoes the lack of a standard, or even specification (code isn't a specification), not put a stop to this? I would expect a language in the kernel I run to at least have a stable specification or standard. I might be the old man screaming at the cloud.
Code in the form of a test is.
It shows how you can interact with the system/component/unit under test.
A specification should specify behavior, edge cases, time complexity, possible pitfalls, etc.
Basically anything that is guaranteed (by the specification). A test may test a quirk of the implementation.
I'm not sure this is a real concern for the Linux kernel devs.
IIRC there was only a concern around allocation but the rust std is moving to fallible allocations for that reason (and the rust integration seems to ship their own std lib anyway)
Otherwise there is no issue in redefining panic() to call the kernel oops handler and have the kernel perform a coredump.
Rust is entirely fine working with custom allocation stuff, there isn't any hidden allocator calls in you can make (well, the box operator, but that has been nightly forever and likely won't appear outside the stdlib ever).
The box operator allows moving the initialization of a datastructure into the heap entirely (and the compiler also auto-insert the malloc calls).
It is largely a one-trick pony that only exists to help out the standard library, nobody should be using it ever. But it is the one instance where the rust compiler will deploy an allocation on the heap without any obvious way to tell that it did that.
It's my understanding the Rust for Linux project has integrated custom fallible allocations (so, works for them, see: https://github.com/Rust-for-Linux/linux/pull/402), but the fallible allocator API is not yet stabilized for Rust itself (see: https://github.com/Rust-for-Linux/linux/issues/2).
> I would expect a language in the kernel I run to at least have a stable specification or standard.
I hear this occasionally, and I guess I'd like to better understand it. If a document existed that was called "The Rust Specification", why/how would that be significant for kernel development?
Maybe I'm dense, but why is this necessary, or specifically helpful, re: kernel development? As I understand it, the Linux kernel doesn't assiduously follow the C spec (it uses many GNU specific extensions). And C spec itself is often not fully implemented on many platforms (see C11 Annex K). If the answer is "It could break", well, Rust probably does more to prevent breakage than any language I know. Definitely more than the C spec ever has.
Would it be nice for the devs to take an extended holiday to write a mind-numbing technical document for the benefit of 2-3 teams working on alternative compilers? Maybe? But, also, maybe not.