Re: why panic(9) ?

From: C. P. Ghost <cpghost_at_cordula.ws>
Date: Tue, 11 Jan 2011 23:08:26 +0100
On Tue, Jan 11, 2011 at 10:43 PM, Chuck Swiger <cswiger_at_mac.com> wrote:
> On Jan 11, 2011, at 1:11 PM, David DEMELIER wrote:
>> 2011/1/11 Chuck Swiger <cswiger_at_mac.com>:
>>> [ ... ]
>>>> Yes, why this function exists? There is no way to solve a problem
>>>> without panic'ing? Is panic really needed?
>>>> Seriously, I really hate when I play some music that suddenly the
>>>> music get stucked in a infinite loop, why ?
>>>
>>> Probably a bug in the sound card driver.
>>
>> No no, it was a panic that didn't core dump so I needed to do a hard reboot.
>
> Frankly, audio isn't (or doesn't seem to be) a core goal of FreeBSD.  Macs are probably the best reference platform available for pro A/V work.  [1]

But the point here is still that a bug in a driver causes
the whole system to hang or panic(). This is precisely
the problem with monolithic systems. I know, I know,
that's an old and tired discussion, but it is (still) a part
of the problem.

As far as I know, Windows NT is a microkernel arch, and
faulty drivers, often provided by external vendors would not
bring that system (as much as we hate or despise its
Windows OS personality that runs on top of it) to a complete halt.

Maybe we should also think about this in the context of BSD...
especially considering the ever increasing amount of hardware
and drivers. Something like a microkernelized and compartimentalized
BSD on top of, say, L4Ka::Pistachio (which is itself BSD-licensed
and which provides super-fast IPC, so performance won't take a
major hit as it did with BSD on top of Mach, a.k.a. Mac OS X) would
be a lot more robust w.r.t. to faults. Sure, not every error would be
harmless, even on such a system, but it would be a long way towards
a more robust and fault-tolerant OS.

But again, this is a major undertaking, and talk about it is cheap... ;)

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
Received on Tue Jan 11 2011 - 21:08:27 UTC

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