Re: why panic(9) ?

From: Garrett Cooper <gcooper_at_FreeBSD.org>
Date: Tue, 11 Jan 2011 15:03:43 -0800
On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER
<demelier.david_at_gmail.com> wrote:
> Hello,
>
> I'm just guessing why current BSD panic() when a problem occurs, all
> modern operating systems solve the problem instead of crashing
> suddently and corrupting all your data without saving your work.
>
> Yes, why this function exists? There is no way to solve a problem
> without panic'ing? Is panic really needed? Imagine someone working on
> something really important and his computer just panic, his work not
> saved everybody shout at him in the corporation. He lose his job, his
> wife, his dog, everything is wrong, just because of a panic() !
>
> Seriously, I really hate when I play some music that suddenly the
> music get stucked in a infinite loop, why ? I don't know because the
> panic does not core dump. But after some search I found that the panic
> was done because of conky. How the hell conky can panic FreeBSD? We
> are in 2011 ! I think even Window 2000 does not crash on a user-land
> software.
>
> I'm guessing now, if minix panic when a bloated crappy software is
> running. I think Andrew is in the right way.

    So I guess with that reasoning we don't need asserts, bugs never
occur, and the if the computer catches on fire we should just let it
burn up instead of getting an extinguisher and put it out :D?
    As an example: I would rather have my PC panic and not write out
corrupt data to disk instead of write out that corrupt data to disk.
The latter has happened with userland apps on occasion before they
crash, and that really fries my bacon... Similarly, if we're beyond
recovery, panicing is the best and only option, but yes... recovery
could be handled better in some cases. Filesystems are a bit trickier
though because they're more mission critical than say a non-critical
device driver (my sound driver?) tanking.
Thanks,
-Garrett
Received on Tue Jan 11 2011 - 22:03:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:10 UTC