[2797] in linux-net channel archive
Re: Network module autoprobing in 1.3
daemon@ATHENA.MIT.EDU (Avery Pennarun)
Sun May 5 13:08:06 1996
Date: Sat, 4 May 1996 13:37:05 -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: <9605020155.AA20782@rsphy6.anu.edu.au>
On Thu, 2 May 1996, Paul Gortmaker wrote:
> Before I go any further with this discussion, let me point out that
> of the *eight* 8390 based drivers that I modularized, *seven* of them
> will already allow an autoprobe if no io= is given, just like Avery
> is arguing for. These seven probes are pretty safe, and the driver
> just prints a small warning stating that module autoprobing is not
> recommended. These probes usually only involve a couple i/o reads.
> No i/o writes take place until the driver is 100% sure a card is there.
>
> The eighth one, as you have probably already guessed, is the ne2k.
> It is a bare-bones 8390 chip with some RAM hanging off of it. There is
> *no* way to determine if a ne2k is at a non-empty (i.e. not 0xff) i/o
> port without *writing* to some ports, and seeing how what is there
> reacts. Since this probe has the ability to disturb anything that it
> probes into due to these writes, it is not allowed to autoprobe as a
> module, which is pretty sensible.
Okay, I didn't know that. Of course my original message was about
IRQ-probing, which is (quite understandably) not presently supported but
which probably should be, and you agreed. After that things got a little
out of control :)
On the other hand, perhaps I should explain my particular interest in an
NE2000 module probe. Since most people wouldn't need it, I haven't
brought it up before.
Basically, I work as tech support for a computer store here in Thunder Bay,
Ontario, Canada. I have found many times that when DOS or Win95-based
drivers just can't locate a card I'm looking for (and of course I have no
manual to do it myself), Linux usually can. This just impresses me, and so
I continue to call Linux's probe routines "extremely well-tested and
reliable." I run into lots of oddball hardware and Linux just doesn't crash
it, for whatever reason. There may be a few drivers that aren't in the
"extremely well-tested" category but I still haven't run into problems, for
whatever reason.
On the other hand, I don't like to compile kernels with LOTS of options
thrown in, so if I need to probe for the address or type of some
particularly strange hardware I need to either a) use the module version or
b) compile a special kernel with the right option included.
NE2000-compatible cards are (however unfortunately) still some of the most
common ethernets around, and presently only option (b) is available to me.
Since the probe routines work fine, I would really like to be able to use
them as a module instead.
Presently the arguments that have been presented still don't explain to me
why something that _can_ be done, very easily, isn't allowed.
> > 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
>
> Hrrm. Consider a novice faced with an install screen asking him to tick
> the boxes for the hardware that he/she wants the install to probe for.
> If they haven't a clue, chances are they will tick every box.
If they happen to be presented with that screen, it was likely made by a
distribution maintainer who ought to know the correct order to probe in. In
that case, as I believe you've said, the ne2000 probe is just as safe as a
module as in the kernel.
> > 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
>
> Yes. If you have BL at 0x330 and aha154x at 0x334, and insmod the
> aha154x driver first, it will grab the BL card and not the aha card.
> The Bl driver will then fail to insmod, as it won't touch the aha card.
>
> > 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
>
> Not caring just because you think it seems like a rare hardware setup
> isn't a good enough reason to just disregard the issue. And yes, they
> should be prepared to read the instructions, but as we all know, the
> average person has a go at it before even considering to RTFM.
Sorry, I didn't mean that I don't care about the problem, I just meant to
say "I've never noticed (thus cared) because I've never run into it."
Certainly it would be good to compensate for it, but this example is IMHO
not good enough to completely disable buslogic and AHA probes as modules.
As a side note, is there absolutely no way to distinguish between the two
cards during probing?
> > Disabling a feature simply because uneducated users might crash their
> > computer by using it is the Windows 95 way. If autoprobe is available
> > (and
>
> Hey, no need to stoop to insults here. ;-) Consider probing for > 64MB
> of RAM. Linus said he'd add such a feaure if somebody wrote it, but it
> would be disabled by default for reasons similar to the above.
First, sorry again, I didn't mean to insult anyone in the above. It's just
that is one of my major complaints about Windows 95 is that it won't let me
do things I want to do because it thinks I shouldn't. Software that thinks
it's smarter than me, even if it really is smarter than me, is annoying.
Also, the example of the >64MB probe seems to support my point of view as
much as yours. Maybe all probes should be disabled by default - and they
are, really. If you have only a Buslogic card, you will not usually compile
your kernel with AHA support. And if everything is a module, you will
generally not try to insert a module for hardware you don't have. Most
often if you do it will be in a controlled situation such as a distribution
maintainer would set up, making modules no less dangerous than the kernel
itself.
> > in the case of Linux, generally extremely well-tested and reliable) I
> > would like to have it used.
>
> Fine. Seven of the eight 8390 cards let you autoprobe now, and I
> wouldn't even go so far as to call it extremely well tested and
> reliable, since I only implemented those changes around mid-Nov for
> something like patch-41.
>
> FWIW, Donald is also of the viewpoint that not allowing the ne2k to
> autoprobe as a module is The Right Thing To Do (tm).
>
> > 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
>
> Or they can use the "Hey, it worked last time, so why should I go and
> edit some silly config file that I know nothing about." approach.
Okay, crazy idea:
Why not have _all_ drivers default to "probe disabled." As you say, it's
unsafe and the order is important. If someone tries to insert the module
without any parameters on the command line, make them all say something
like: "Cannot insert this module because no parameters were given. If you
would like to auto-probe for the device (WARNING! This can be dangerous on
a running system!) use probe=1."
This means people don't have to look in a manual for the option. Plus it
would be consistent between different drivers, and would make sure people
have made a conscious decision to autoprobe instead of pass the information
on the command line.
It's just as easy for distribution maintainers and very little extra effort
for other people. It also gets people like me out of your way because
presumably the ne2000 could be included.
Plus it discourages people from using autoprobing with kerneld, which I
think we'll all agree is just asking for trouble.
> > 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
>
> There are a lot of different systems out there with largely varying
> hardware configurations. That is a pretty big claim to make. Lots of silly
> problems crop up, like the 3c509 ID port and old tape drives, and if Linux
> is to appear as anything other than a hacker' toy, it has to try and deal
> with all possible setups in a sensible manner.
I don't dispute that at all. But autoprobing with playing with modules is a
dangerous game (no argument here!), and people who do it outside of their
distribution maintainer's careful setup are, I think, generally hackers
playing with their toy. Why not let them.
Disclaimer: I think I've been a bit harsh in previous mails. Please don't
take any offense at anything I say; I'm just trying to understand the reason
things are being done the way they are, and perhaps give ideas to improve
them if it is sub-optimal. I'm not trying to stir up trouble.
Have fun!
Avery
