Linux 6.0 arrives with performance improvements and more Rust coming(zdnet.com)
zdnet.com
Linux 6.0 arrives with performance improvements and more Rust coming
https://www.zdnet.com/article/linux-6-0-arrives-with-performance-improvements-and-more-rust-coming/
2 comments
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.
I'm not sure this is a real concern for the Linux kernel devs.
> Has the Rust panic() issue been resolved?
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?
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?
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.
> 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.
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.
Linus also famously hates parts of the C spec and so actively does not follow it: https://news.ycombinator.com/item?id=17262643
What panic() Issue are you referring to?
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.
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.
presumably this one: https://lkml.org/lkml/2021/4/14/1099 ?
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).
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).
What is the box operator? This doesn't sound familiar to me, but I also don't use nightly.
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.
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.
Box operator isn't actually used in Box::new anymore. It's been replaced with a magic attribute, #[rustc_box]
[deleted]
> code isn't a specification.
Code in the form of a test is.
It shows how you can interact with the system/component/unit under test.
Code in the form of a test is.
It shows how you can interact with the system/component/unit under test.
Tell me how code in the form of tests is not incredibly specific to a version and implementation of the thing youre testing?
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.
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.
A test is not a specification unless it covers every possible input and output. That’s only possible in a very small set of cases.
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.