[aspaceman]

> it's definitely not what he wrote.

I feel like we must have read two different articles. You sound crazy. Didn't read it your way at all.

> Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.

"If the kernel shuts down the world, we don't get the bug report", seems like a pretty good argument. There are two options when you hit a panic in rust code:

* Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel.

* Ignore the panic and proceed with the information it failed, reporting this failure later.

The kernel is a single program, so it's not like you could just fork it before every Rust call and fail if they fail.

[titzer]

He wrote:

> In the kernel, "panic and stop" is not an option (it's actively worse than even the wrong answer, since it's really not debugable), so the kernel version of "panic" is "WARN_ON_ONCE()" and continue with the wrong answer.

(edit, and):

> Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.

Did I read that right? The kernel must continue? Yes, sure, absolutely...but maybe it doesn't need to continue with the next instruction, but maybe in an error handler? Is his thinking so narrow? I hope not.

[gmueckl]

The error handler is the kernel. Whatever code runs to dump the panic somewhere must rely on some sort of device driver, which in turn must depend on other kernel subsystems and possibly other drivers to work.

There is an enormous variation in output targets for a panic on Linux: graphics hardware attached to PCIe (requires graphics driver and possibly support from PCIe bus master, I don't know), serial interface (USART driver), serial via USB (serial over USB driver, USB protocol stack, USB root hub driver, whatever bus that is attached to)... There is a very real chance that the error reporting ends up encountering the same issue (e.g. some inconsistent data on the kernel heap) while reporting it, Which would leave the developers with no information to work from if the kernel traps itself in an endless error handling loop.

[jstimpfle]

In the case of WARN() macros, it will be continued with whatever the code says. There is no automatic stack unwinding in the kernel, and how errors should be handled (apart from being logged) must be decided case-by-case. It could just be handled with an early-exit returning an error code, like other "more expected" errors.

The issue being discussed here is that Rust comes from a perspective of being able to classify errors and being able to automate error handling. In the kernel, it doesn't work like that, as we're working with more constraints than in userland. That includes hardware that doesn't behave like it was expected to.

[titzer]

Well, you've edited your reply a couple times, so it's a moving target, but:

> * Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel.

No one is really advocating that. Clearly you need to be able to write code that fails at a smaller granularity than the whole kernel. See my comment upthread about what I mean by that: dynamic errors fail smaller granularity tasks and handlers deal with tasks failing due to safety checks going bad.

[aspaceman]

Ease the snark space ranger.

> dynamic errors fail smaller granularity tasks and handlers deal with tasks failing due to safety checks going bad.

Yes and that's why Rust is bad here (but it doesn't have to be). Rust _forces_ you to stop the whole world when an error occurs. You cannot fail at a smaller granularity. You have to panic. Period. This is why it is being criticized here. It doesn't allow you any other granularity. The top comment has some alternatives that still work in Rust.

[titzer]

> You cannot fail at a smaller granularity.

Rust needs to fix that then. So we agree on that.

[Jweb_Guru]

What was said is not actually true of Rust.

[__jem]

> Rust _forces_ you to stop the whole world when an error occurs.

But... this isn't true??