4 ms·

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 specif

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.

mihaigalos 4y ago
> 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.
- klysm 4y ago
  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.
- lionkor 4y ago
  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.
solar-ice 4y ago
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.
zaarn 4y ago
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.
- signa11 4y ago
  presumably this one: https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099 ?
  - zaarn 4y ago
    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).
    - rascul 4y ago
      What is the box operator? This doesn't sound familiar to me, but I also don't use nightly.
      - zaarn 4y ago
        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.
        DrMeepster 4y ago
        Box operator isn't actually used in Box::new anymore. It's been replaced with a magic attribute, #[rustc_box]
mustache_kimono 4y ago
> 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 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 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?
- lionkor 4y ago
  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.
  - mustache_kimono 4y ago
    > 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.
    - steveklabnik 4y ago
      Linus also famously hates parts of the C spec and so actively does not follow it: https://news.ycombinator.com/item?id=17262643 https://news.ycombinator.com/item?id=17262643
deleted 4y ago
[deleted]

mihaigalos 4y ago

> 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.

klysm 4y ago
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.
lionkor 4y ago
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.

solar-ice 4y ago

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.

zaarn 4y ago

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.

signa11 4y ago
presumably this one: https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099 ?
- zaarn 4y ago
  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).
  - rascul 4y ago
    What is the box operator? This doesn't sound familiar to me, but I also don't use nightly.
    - zaarn 4y ago
      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.
      - DrMeepster 4y ago
        Box operator isn't actually used in Box::new anymore. It's been replaced with a magic attribute, #[rustc_box]

mustache_kimono 4y ago

> 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 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 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?

lionkor 4y ago
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.
- mustache_kimono 4y ago
  > 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.
  - steveklabnik 4y ago
    Linus also famously hates parts of the C spec and so actively does not follow it: https://news.ycombinator.com/item?id=17262643 https://news.ycombinator.com/item?id=17262643

deleted 4y ago

[deleted]