5 ms·

> but the OOM killer!" [..] disaster for Rust [...] Only on HN discussions (the disaster part) ;=) (Through it's is a broken discussion, OOM on Linux is bro

> but the OOM killer!" [..] disaster for Rust [...] Only on HN discussions (the disaster part) ;=) (Through it's is a broken discussion, OOM on Linux is broken, but it becomes increasingly "un-"broken and like you said other platform exists, too). Anyway there is no disaster as: Rust does support handling memory allocations gracefully, the allocator API defaults to this!! Just various types defined in [lib]std (or precise [lib]alloc) default in there default methods to calling the (replaceable!) allocation error hook. This is due to ergonomics, there is no sane/ergonomic way for "common non embedded/kernel programming or non special purpose use-cases" to make literally every method which potentially allocates return a result. And outside of such special purpose cases you can always recover from panics (i.e. outside of special purpose cases panic=abort is a anti-pattern). Still, even in std, methods like `try_reserve` exists and are used, e.g. by serde deserializers to make sure to gracefully fail if the user tries to allocate a 10GiB array (because compressed data formats ;-) ). BUT for the kernel all this doesn't matter as it is very unlikely it will use [lib]std or [lib]alloc. So they can default to just always implement their types in a way which doesn't panic on memory allocation. And wrt. to panic in other (basically guaranteed to be a bug cases) panic=BUG() (ther kernel BUG() macro) can be done. I'm more worried about the float/128bit integer thing he mentioned, as I don't know anything about it. I assume it's not just a miss understanding of overflow checks and other debug assertions the kernel likely will disable for non-debug builds?

littlestymaar 6y ago
> I'm more worried about the float/128bit integer thing he mentioned, as I don't know anything about it. I assume it's not just a miss understanding of overflow checks and other debug assertions the kernel likely will disable for non-debug builds? Idk about 128bits integer, but the floating point question has been discussed on Rust's subreddit[1]: > Normally, the kernel leaves the floating-point state of the CPU in whatever state the userspace process left it in, so that you can do a quick system call without having to save and restore all that state. It's possible to use floating point in the kernel with a great deal of care, but you have to notify the kernel that you're doing so, so that it can save the userspace floating-point state. > So, it'd be helpful if by default Rust didn't allow use of floating-point, and then you could opt in to allowing it for specific code. And from Linus[2] > In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL. [1]: https://www.reddit.com/r/rust/comments/mqxr1a/rfc_rust_support_for_linux_kernel/gujty1u/?context=3 https://www.reddit.com/r/rust/comments/mqxr1a/rfc_rust_suppo... [2]: (from the same reddit thread) https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/linux/kernel_fp.html https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47i...
- dathinab 6y ago
  Well if that it all this could be solved by rust by having a "floating_point_usage" (or similar) lint which normally defaults to "allow" but for kernel devs defaults to "error" (which could be done through an option in the target spec, which as a side note is also what defines if you have hard,soft or no fp support). (there are probably better solution but this one should be the easiest).
  - ssokolow 6y ago
    There's actually a lint specifically intended for that already. `float_arithmetic`: https://rust-lang.github.io/rust-clippy/master/#float_arithmetic https://rust-lang.github.io/rust-clippy/master/#float_arithm... # What it does Checks for float arithmetic. # Why is this bad For some embedded systems or kernel development, it can be useful to rule out floating-point numbers.
    - dathinab 6y ago
      Thanks, nice, but for the kernel use case it would need to be part of rustc.
      - zaarn 6y ago
        Simply install clippy and call "clippy-driver" instead of "rustc", which will handle this. Clippy is largely the lints that haven't either made it into rustc or are fairly edge-case-y.
      - littlestymaar 6y ago
        Why? The Rust-for-Linux team already made Clippy a requirement for Rust kernel code. For niche configuration that are really project-specific like this, it makes total sense to use external tooling to ensure the guidelines are respected, it doesn't need to be the compiler enforcing these guidelines.

littlestymaar 6y ago

> I'm more worried about the float/128bit integer thing he mentioned, as I don't know anything about it. I assume it's not just a miss understanding of overflow checks and other debug assertions the kernel likely will disable for non-debug builds? Idk about 128bits integer, but the floating point question has been discussed on Rust's subreddit[1]: > Normally, the kernel leaves the floating-point state of the CPU in whatever state the userspace process left it in, so that you can do a quick system call without having to save and restore all that state. It's possible to use floating point in the kernel with a great deal of care, but you have to notify the kernel that you're doing so, so that it can save the userspace floating-point state. > So, it'd be helpful if by default Rust didn't allow use of floating-point, and then you could opt in to allowing it for specific code. And from Linus[2] > In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL. [1]: https://www.reddit.com/r/rust/comments/mqxr1a/rfc_rust_support_for_linux_kernel/gujty1u/?context=3 https://www.reddit.com/r/rust/comments/mqxr1a/rfc_rust_suppo... [2]: (from the same reddit thread) https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/linux/kernel_fp.html https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47i...

dathinab 6y ago
Well if that it all this could be solved by rust by having a "floating_point_usage" (or similar) lint which normally defaults to "allow" but for kernel devs defaults to "error" (which could be done through an option in the target spec, which as a side note is also what defines if you have hard,soft or no fp support). (there are probably better solution but this one should be the easiest).
- ssokolow 6y ago
  There's actually a lint specifically intended for that already. `float_arithmetic`: https://rust-lang.github.io/rust-clippy/master/#float_arithmetic https://rust-lang.github.io/rust-clippy/master/#float_arithm... # What it does Checks for float arithmetic. # Why is this bad For some embedded systems or kernel development, it can be useful to rule out floating-point numbers.
  - dathinab 6y ago
    Thanks, nice, but for the kernel use case it would need to be part of rustc.
    - zaarn 6y ago
      Simply install clippy and call "clippy-driver" instead of "rustc", which will handle this. Clippy is largely the lints that haven't either made it into rustc or are fairly edge-case-y.
    - littlestymaar 6y ago
      Why? The Rust-for-Linux team already made Clippy a requirement for Rust kernel code. For niche configuration that are really project-specific like this, it makes total sense to use external tooling to ensure the guidelines are respected, it doesn't need to be the compiler enforcing these guidelines.