4 ms·

Linux will definitely need a very curated setup to reap the full benefits of idiomatic Rust. Right now both alloc/std and even basic language constructs like i

Linux will definitely need a very curated setup to reap the full benefits of idiomatic Rust. Right now both alloc/std and even basic language constructs like indexing into a slice can panic. With little help from the tooling to guard against it. This makes sense when considering that Rust evolved as a language for writing somewhat higher level applications like browsers. While Rust and especially the library ecosystem is generally great at forcing you to handle application domain error conditions, that mostly doesn't extend to these lower-level concerns. But I'm hopeful that this can improve the entire ecosystem over the medium term. With things like lints that forbid panics, more focus on custom allocators and fallible allocations in std and the library ecosystem, etc. edit: just to clarify on the slice index panicking: my point isn't that the C situation is better, but that a big reason for moving to Rust would be to benefit of a safer, more convenient language that doesn't require such extreme carefulness as C. So the language should help in preventing panics, or making it obvious where they can occur. This is perfectly possible in Rust by using accessors that return `Option<T>` or iterators. But the tooling for such use cases can be improved, for example with lints, and the API surface can be customized to mostly prevent such conditions with the type system.

nynx 5y ago
A rising tide lifts all boats! I'm really looking forward to the improvements that come to the rust ecosystem from integration into Linux.
wyldfire 5y ago
> Right now both alloc/std and even basic language constructs like indexing into a slice can panic AFAIK they're not using std. And isn't this kind of panic the kind of thing that causes BUG()s today? Probably can just map one to the other.
- btbuilder 5y ago
  out of memory conditions should not cause a kernel panic.
  - simias 5y ago
    The kernel uses a non standard `kmalloc` to allocate memory anyway, I don't know how they plan to integrate Rust into the kernel but I would be very surprised if they imported any of Rust's std as-is. Actually most of the time you probably wouldn't want a Vec that reallocates automatically in the kernel, you'd probably want a dynamically allocated array of fixed length the majority of the time.
- codys 5y ago
  Yes, indexing into arrays in C (well, really, de-referencing pointers) in ways that are out of bounds will in the best case result in a fault which results in a BUG() invocation in Linux. Panicing on invalid slice indexing is a non-issue.
  - a1369209993 5y ago
    > Panicing on invalid slice indexing is a non-issue. Well, it's less of a issue that what we already have. It would still be nice to be able to tell the compiler: "Issue a diagnostic for any [some qualifiers] panic that isn't optimized out by unreachable code analysis.".
fpoling 5y ago
There is no index checks in the current kernel C code at all. It is better to panic than violate memory safety.
- dvt 5y ago
  > There is no index checks in the current kernel C code at all. It is better to panic than violate memory safety. This isn't the question here. malloc (or other memory operation) failures should never panic. According to Torvalds[1]: > Allocation failures in a driver or non-core code - and that is by definition all of any new Rust code - can never EVER validly cause panics. Same goes for "oh, some case I didn't test used 128-bit integers or floating point". Kernel code is a bit quirky in this sense that it will always favor system stability (and expect proper errors to trickle down) instead of crashing. Also, Linux runs on plenty of low-memory embedded systems so failing on a malloc may not even be a particularly rare occurrence. [1] https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099
  - comex 5y ago
    The parent post mentioned both allocation and indexing. Both have the potential to panic in Rust programs based on the full standard library. Allocation needs to be dealt with, as you mention, but out-of-bounds indexing could likely continue to be a Rust panic, which could be translated to a Linux BUG() call.

nynx 5y ago

A rising tide lifts all boats! I'm really looking forward to the improvements that come to the rust ecosystem from integration into Linux.

wyldfire 5y ago

> Right now both alloc/std and even basic language constructs like indexing into a slice can panic AFAIK they're not using std. And isn't this kind of panic the kind of thing that causes BUG()s today? Probably can just map one to the other.

btbuilder 5y ago
out of memory conditions should not cause a kernel panic.
- simias 5y ago
  The kernel uses a non standard `kmalloc` to allocate memory anyway, I don't know how they plan to integrate Rust into the kernel but I would be very surprised if they imported any of Rust's std as-is. Actually most of the time you probably wouldn't want a Vec that reallocates automatically in the kernel, you'd probably want a dynamically allocated array of fixed length the majority of the time.
codys 5y ago
Yes, indexing into arrays in C (well, really, de-referencing pointers) in ways that are out of bounds will in the best case result in a fault which results in a BUG() invocation in Linux. Panicing on invalid slice indexing is a non-issue.
- a1369209993 5y ago
  > Panicing on invalid slice indexing is a non-issue. Well, it's less of a issue that what we already have. It would still be nice to be able to tell the compiler: "Issue a diagnostic for any [some qualifiers] panic that isn't optimized out by unreachable code analysis.".

fpoling 5y ago

There is no index checks in the current kernel C code at all. It is better to panic than violate memory safety.

dvt 5y ago
> There is no index checks in the current kernel C code at all. It is better to panic than violate memory safety. This isn't the question here. malloc (or other memory operation) failures should never panic. According to Torvalds[1]: > Allocation failures in a driver or non-core code - and that is by definition all of any new Rust code - can never EVER validly cause panics. Same goes for "oh, some case I didn't test used 128-bit integers or floating point". Kernel code is a bit quirky in this sense that it will always favor system stability (and expect proper errors to trickle down) instead of crashing. Also, Linux runs on plenty of low-memory embedded systems so failing on a malloc may not even be a particularly rare occurrence. [1] https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099
- comex 5y ago
  The parent post mentioned both allocation and indexing. Both have the potential to panic in Rust programs based on the full standard library. Allocation needs to be dealt with, as you mention, but out-of-bounds indexing could likely continue to be a Rust panic, which could be translated to a Linux BUG() call.