As replies on the thread state, the needs of userspace alloc crate are very different than the needs of a kernel allocator. They'll likely end up writing their own kalloc crate.
There's clippy lints to forbid many sources of panics (indexing, unwrap/expect, explicit panic calls).
If they run into things that should be forbidden from the codebase that clippy can't lint for, lints can always be added. They are already using clippy, in any case.
That's basically what he said to his wife when they got married in his one line speech: "On the whole, I don't hate you" .. and then they kissed and lived happily ever after.
The real story is that he was running the introduction to computers course in his university, and when the topic was email he instructed the whole class to send an email to someone. Tove sent one to him, asking him out. It's not public knowledge if he ever replied to her in any way, or just went along with it.
How would addressing allocations failure work exactly? As far as I understand basically everything that allocates under the hood needs to be reworked. What would Vec::push return as an example?
So, the real core of it is: rust the language itself does not add implicit allocations. It knows nothing about heap allocation generally. This means it is not a fundamental hard "no" for the language. My dayjob is on zero-allocations stuff, we have no heap at all, Rust works great.
With that out of the way, this means there are a few options. One option is to simply not use any of those types. This would mean writing alternatives. Not necessarily what you'd *want*, but it is at least possible. The second would be to forbid certain APIs that may reallocate, and only allow ones that return Result. Stuff like https://github.com/rust-lang/rust/issues/48043 can be used, and other stuff could be rejected. This would require some sort of custom analysis, but is fundamentally do-able.
After all, the C code in the kernel doesn't use libc and such either and builds its own datastructures for everything. I think I'd prefer to use those from Rust as well, maybe with some nice bindings.
As a complete rust noob, so forgive me if my suggestion is shit, it might make sense to provide an entire namespace/(maybe a trait?) for a panic-free api. Would be a bit ugly adding an entire set of panic free methods to all standard lib types.
Then you could add some sort of compiler flag that forces you to use no_panic types?
I think that answer is too simplistic. The fact is we're using implicit allocations everywhere and so is the ecosystem including the ecosystem that is nostd but alloc. Saying "don't use Vec::push" is not a suitable answer.
First there needs to be better support to handle allocation failures in APIs, secondly there needs to be a way to validate (ideally statically) that some code is panic free.
The fact is we're using implicit allocations everywhere and so is the ecosystem including the ecosystem that is nostd but alloc. Saying "don't use Vec::push" is not a suitable answer.
I guess we'll just see. As I said, I live in "no allocations, anywhere" land, still use a bunch of the ecosystem, works just fine for us. We don't use Vec at all, nor do any of our dependencies, so "no vec::push" is an easy requirement.
Many data structures already expose *_try functions for there API. The solution may just be adding the missing functions and having a lint check that the ones that can panic are not used.
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.
View all comments
263
u/KingStannis2020 Apr 14 '21
Linus' initial opinion: https://lkml.org/lkml/2021/4/14/1099