There are literally millions of things he didn’t say. He did however express a requirement for acceptance. That’s the message, if you want this in the kernel, it has to never call panic() at run time. Why? Because kernel crashes are unacceptable for the types of deployment Linux is used for.
I not sure he mean never panic at runtime. I think there are good reason to panic at runtime if you care about safety a buffer overflow is a good reason for instance.
But a memory allocation failure is clearly not a good reason.
> With the main point of Rust being safety, there is no way I will ever accept "panic dynamically" (whether due to out-of-memory or due to anything else - I also reacted to the "floating point use causes dynamic panics") as a feature in the Rust model.
WRT floating-point, worth noting for those who haven't read the patches:
- Kernels generally don't want to use floating-point, because saving and restoring the floating-point registers is fairly expensive.
- Without some pretty aggressive hacking, it's not possible to remove floating-point support from Rust.
- What you /can/ do (and what these patches do) is replace all the floating-point builtins with kernel panics.
- This obviously sucks versus actually removing the floating-point, but this is an RFC.
There is some work in progress to make it easier to tell Cargo to build `core`/`alloc`, which in turn would allow projects to maintain patches atop them like disabling floating-point or oom-panicking APIs entirely. I suspect that this effort will get a great deal of motivation from being a kernel requirement
I think the gist of what he is saying is typical application programming patterns like crash on exception, gc, etc. are not a good fit for kernel programming. And I agree. Handle the request or return an error and let higher level code handle the error processing.
Out of memory allocation panic is absolutely not acceptable in a kernel, and even less so when you're linux (which does some sneaky memory overcommit things)