Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!bofh.dot!in-news.erinet.com!imci5!imci4!newsfeed.internetmci.com!in1.uu.net!01-newsfeed.univie.ac.at!news.iif.hu!ludens.elte.hu!not-for-mail
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs. FreeBSD ...
Message-ID: <31a74799.0@kaliban.csoma.elte.hu>
From: mingo@kaliban.csoma.elte.hu (Ingo Molnar)
Date: 25 May 96 17:47:05 GMT
References: <3188C1E2.45AE@onramp.net> <318FD68B.60AD12F6@lambert.org>
Nntp-Posting-Host: kaliban.csoma.elte.hu
X-Newsreader: TIN [UNIX 1.3 BETA-950824-color PL0]
Lines: 95
Terry Lambert (terry@lambert.org) wrote:
: Ingo Molnar wrote:
<snip>
: ] but it really doesnt render your OS useless or less clean ...
: ] there are alot of device drivers with code quality ranging from
: ] "perfect" to "poor".
:
: A hack driver may, in fact, render your kernel unbootable on
: a large amount of hardware.
yes, but this the way Linux does it:
- first nonintrusive probes, good hardware gets detected
- detected hardware reserves it's IO region via reserve_region(),
thus "secondary" probes cant break an already detected
"good" hardware.
- within the driver there is probe-ordering too. So for example,
there are a few ArcNet cards which need an outw() to a critical
port to get detected properly. This outw() is issued if all other
probes failed. The ArcNet driver is a "late" card in the general
chain. The chain is pre-defined in the kernel.
so if you have one hack driver in your system, then probably it
does it's autoprobing at the end -> all your good drivers will work.
Your system can break if:
1) the driver is very bad and not put correctly in the probe
chain. Drivers that go into Linus' kernel are defined properly.
2) you compile bogus and intrusive drivers into your kernel.
both are bad system administrator decisions. The third breakage is "real":
3) two or more intrusive drivers are in the chain
From the theoretical point of view, 1 "intrusive" device is acceptable.
Linux allows an arbitrary number of intrusive devices, so this isnt
a "clean" solution, but the experience is that the three methods used
(driver-chain, reserve_region() and in-driver-ordering) work for
99.99% of the cases even if there are more than one intrusive drivers.
(assuming that you have the hardware!).
The probe-ordering is a well-coordinated and well-understood issue
amongst Linux device driver writers.
Well, there >IS< a solution, a "device detection database" that orders
intrusive writes and detects "deadlocks" (or "hazards"), but this is
unrealistic currently i think. We could even "rotate" deadlocks
between reboots ... :)
: Intrusive probing is inherently evil.
yes, but experience shows that this isnt an issue for Linux even if
you have bad hardware, if:
- you know what hardware you have
- you compile only those drivers
and note that good hardware >always< gets detected right in Linux if
you fulfill the above requirements.
: Any hardware that requires intrusive probing to identify it
: is "hack hardware".
: Drivers for "hack hardware" are *immediately* and *irrevocably*
: "hack drivers".
:
: If your drive can screw up in *any* way other than to not drive
: the device for which it was intended, then it's broken.
it cant break "good hardware only system". It cant even break
"good hardware in a mixed system". It can break "bad hardware
in a mixed system". This is much more than FreeBSD's "good hardware
only" policy i think.
: You can only take care of so much of this by ordering device
: probes to make sure the good hardware is found first so that
: the crappy hardware driver "doesn't try there".
yes. exactly. i dont see your point then :*(
: ] If you were a hard-core purist, then you would have never touched
: ] any PC keyboard ...
:
: I'm not a hard core purist; I'm a quality control purist.
well, i think of device drivers rather as "applications in the kernel",
not as "the kernel itself". To get them right is the responsibility
of the system manager, not the kernel designer.
-- mingo