Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!bofh.dot!in-news.erinet.com!imci5!pull-feed.internetmci.com!news.internetMCI.com!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs. FreeBSD ...
Date: Sat, 25 May 1996 16:08:54 -0700
Organization: Me
Lines: 98
Message-ID: <31A79306.278FBB7C@lambert.org>
References: <3188C1E2.45AE@onramp.net> <318FD68B.60AD12F6@lambert.org> <31a74799.0@kaliban.csoma.elte.hu>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Ingo Molnar wrote:
] 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
I don't have a problem with any of this. I note that #2 in the
FreeBSD case is "activated bogus and/or intrusive drivers". And
this is, in fact, how FreeBSD handles the problem.
] From the theoretical point of view, 1 "intrusive" device is
] acceptable.
Yeah. The only problem is that all ISA card manufacturers
want their device to be "the one". 8-(.
] 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 ... :)
This is, in fact, exactly what Windows 95 does during install,
with it's activity logging and "hit reset is this takes too
long" and "resume install".
So it's hardly unrealistic.
] : 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 Linux distributions typically include 8 or more boot disks
to deal with this eventuality, which seems to me to be an
unacceptable soloution. If I buy a new box, it's entirely
possible that (as Joe Consumer, not as Terry 8-)) that I won't
know *what* hardware is actually in the box.
] and note that good hardware >always< gets detected right in Linux if
] you fulfill the above requirements.
Which does you no good if bad hardwre or bad drivers cause your
system to crash anyway (unless you adopt the probe failure logging
used by Windows 95).
] : 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.
First, I don't speak for FreeBSD policy. I speak for my personal
policy.
Second, a bad probe for not-present hardware can break good
hardware. You'v drawn a map:
,-.
|A| a
`-+---.
| |
b| B |
| |
`---'
And only covered 'A' and 'B' and 'a'.
b == bad drivers, only good hardware.
] 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.
The problem with this is that it then requires a system manager;
things which "just work" don't require management.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.