zlacker

[parent] [thread] 5 comments
1. charci+(OP)[view] [source] 2022-10-02 15:44:21
panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.
replies(3): >>wtalli+p5 >>Someon+g7 >>second+Ub
2. wtalli+p5[view] [source] 2022-10-02 16:14:05
>>charci+(OP)
Printing debug information to the kernel log then immediately triggering a kernel panic is not as useful as it sounds, because that approach will quite often result in that debugging information never reaching a display or any kind of persistent storage.
3. Someon+g7[view] [source] 2022-10-02 16:23:48
>>charci+(OP)
And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing).

Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're in a panic the IO could have been literally pulled out.

replies(1): >>charci+9H
4. second+Ub[view] [source] 2022-10-02 16:45:58
>>charci+(OP)
Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?
replies(1): >>charci+WG
◧◩
5. charci+WG[view] [source] [discussion] 2022-10-02 19:56:40
>>second+Ub
Print it to the cloud
◧◩
6. charci+9H[view] [source] [discussion] 2022-10-02 19:57:43
>>Someon+g7
>Keep in mind that in a kernel panic no hardware is assumed to work

So just change that assumption since for these edge cases that is an incorrect assumption.

[go to top]