[2736] in linux-net channel archive
Re: Network module autoprobing in 1.3
daemon@ATHENA.MIT.EDU (Paul Gortmaker)
Tue Apr 30 08:49:14 1996
From: Paul Gortmaker <gpg109@rsphy6.anu.edu.au>
To: apenwarr@foxnet.net (Avery Pennarun)
Date: Tue, 30 Apr 1996 11:33:02 +1000 (EST)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.91.960429134203.3299H-100000@wingnut.foxnet.net> from "Avery Pennarun" at Apr 29, 96 01:48:30 pm
From "Avery Pennarun" at Apr 29, 96 01:48:30 pm
> I always believed that drivers should let me do whatever it is I want,
> within reason. Now, when autoprobing IRQ's in Linux 1.2 locked up the
> machine 100% of the time, it was a good idea not to allow probing as a
> module. However, if an ne2k driver probing "might lock the computer" I
> would like to have the option of trying it anyway.
>
> 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...)
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.
> If nothing else, we could make the default off but make it optional.
> Something like:
> insmod ne2000 krazy=1
>
> 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:
-------------------------
#!/bin/sh
#
# Autoprobe for single ne2000 card -- not recommended -- Paul Gortmaker
#
for i in 0x280 0x300 0x320 0x340 0x360
do
insmod ne2000 io=$i 2> /dev/null
if [ $? = 0 ]
then
echo "Found ne2000 at $i" >&2
exit 0
else
echo "No ne2000 at $i" >&2
fi
done
exit 1
-------------------------
As a bonus, they can specify a different order of addresses, and also
include addresses that the autoprobe wouldn't normally even look at.
Paul.
