[2759] in linux-net channel archive
Re: Network module autoprobing in 1.3
daemon@ATHENA.MIT.EDU (Avery Pennarun)
Wed May 1 19:17:28 1996
Date: Wed, 1 May 1996 13:27:08 -0400 (EDT)
From: Avery Pennarun <apenwarr@foxnet.net>
To: Paul Gortmaker <gpg109@rsphy6.anu.edu.au>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <9604300133.AA09136@rsphy6.anu.edu.au>
On Tue, 30 Apr 1996, Paul Gortmaker wrote:
> > A reasonably intelligent probe shouldn't walk all over addresses which are
> > already allocated anyway, and so the ne2k driver should have the same
> > chance, perhaps less, of killing my computer as a module than if it were
> > compiled in, no?
>
> No, you have a larger chance of killing a computer when using a module
> as compared to when you do the probing at boot (compiled in). There
> are two reasons why this is generally true:
>
> 1) The order of the probing of hardware is well thought out and strictly
> adhered to when drivers are compiled in -- i.e. 1st char drivers, then
> IDE, then SCSI, then ethernet, etc. Also, there is usually ordering in
> those sub-groups, such as BusLogic before aha154x, and SMC-Ultra before
> wd80x3, etc. If you then use modules for all those things, you lose
> that sensible ordering, and have to rely on Joe Random User knowing
> what he/she should insmod first. (Hrrm, BusLogic one before the aha154x
> one? Hey, no problem -- I have a 50% chance of getting it right...)
I think you're missing an important detail - nobody (I hope) is ever going
to try probing _all_ the modules at once. That would be pointless and
defeats the purpose of modules anyway. If a distribution really wants to be
automagic about it, there's no reason they can't do the probe in the same
order as the kernel does. And distribution maintainers should certainly
know how to do that.
Normal people and the current kind of distribution that ASKS you what
hardware to check for basically eliminates the above kind of problem for 99%
of people. For example, I didn't know I had to probe BusLogic before
aha154x (do you really, or is that just the way it's done?). However, I've
never cared because only very few people have both cards in the same
computer. If they do, they should be prepared to read instructions and/or
just pass the addresses on the command line. Or use a well-designed
distribution that does it in the right order by default.
Disabling a feature simply because uneducated users might crash their
computer by using it is the Windows 95 way. If autoprobe is available (and
in the case of Linux, generally extremely well-tested and reliable) I would
like to have it used.
> 2) In a modular configuration, a device is only protected by
> address allocation while its driver is loaded/resident. In other
> words, a device is only protected from other device probes after it has
> been insmod-ed and thus called request_region() to protect itself.
> Say I have a "Foo-Brand" SCSI card at 0x300, and I only load the driver
> for it when doing backups to tape. Also say I have a ne2k at 0x340, and
> I change the driver let it autoprobe addresses during an insmod. I
> insmod the ne2k driver, it autoprobes into 0x300, and the Foo-Brand
> SCSI card hangs the machine. Blecch.
I wouldn't encourage autoprobe for all situations all the time. It can be
more of a first-time thing. With modules, you actually have the opportunity
to save and remember the options once they've been probed. People who use
eg. kerneld deserve what they get if they autoprobe each time the module is
loaded.
On the other hand, I still maintain that most people will not have a
problem. You can come up with sample problems forever, but I'm sure the
vast majority of people will never actually run into them. If they do, you
can still say "I told you so" and "RTFM, don't use the autoprobe on a
running system."
> > If I just don't know where my ne2000 is, it would be nice to be able to
> > at least try. (And generally when I'm doing things like this I know to
> > be at the console and in a very safe situation).
>
> If people (or more likely distribution builders) are keen on trying to
> autoprobe with an ne2k they don't need yet another silly
> "impossible-to-find-documentation-on" (TM) option. They can just do
> something like the following:
[insightful manual address-probing shell script deleted]
Such an idea is very, very inconvenient for those of us who are actually
interested in autoprobing QUICKLY. It takes the brains out of the driver
and leaves the intelligence to a shell script.
For example, probes like my ARCnet driver wouldn't fit this model too well.
For one thing, with all the different manufacturers that make (made) ARCnet
cards, there are a huge number of addresses that may be in use and would
have to be probed, with one module insertion and fork each time. Secondly,
ARCnet cards do not probe terribly easily as they only have one simple
read-status port. The only way to probe one of these effectively is to
reset the card (thankfully only a READ operation on base_add+8), wait a
second or so, and then check the status for a known bitmask. If that passes
(and a couple of other more complicated but safe ones, I'm not that naive),
further checks can be made on the assumption that it's probably an ARCnet
anyway.
The new ARCnet driver uses a variation of that technique in which it resets
all possible ports at once, thus reducing the delay to only a single short
pause. In your script, probing all 50 or so possible IO address would take
50+ seconds.
I consider the ARCnet probe very non-intrusive (as far as probes go - non
ARCnet cards are never WRITTEN to except possibly in extreme cases which
I've yet to discover), so I don't feel bad about whacking 50+ ports in one
shot. It may confuse NE2000 clones, or so I hear, but hey - probe ne2000
first. Cards that lock up the system when you READ them are just bad news
for autoprobing, period.
> As a bonus, they can specify a different order of addresses, and also
> include addresses that the autoprobe wouldn't normally even look at.
If they want to include addresses that the autoprobe wouldn't normally look
at, one of two things is probably true:
1) There is an awfully good reason it wasn't in the probe in the
first place, so distribution maintainers shouldn't include it in
a script like yours. Likewise with changing the probe order.
2) The end user already knows the address of his card, so
autoprobing is pointless anyway.
So in conclusion, if you can autoprobe, I say do it. The ability to disable
this probe manually remains extremely important, of course, but I think the
default should be probe-enabled.
Avery
