[2772] in linux-net channel archive
Re: Network module autoprobing in 1.3
daemon@ATHENA.MIT.EDU (RHS Linux User)
Thu May 2 17:35:26 1996
Date: Thu, 2 May 1996 08:37:35 -0500 (CDT)
From: RHS Linux User <zap@kraken.port-aransas.k12.tx.us>
To: Paul Gortmaker <gpg109@rsphy6.anu.edu.au>
cc: Avery Pennarun <apenwarr@foxnet.net>, linux-net@vger.rutgers.edu
In-Reply-To: <9605020155.AA20782@rsphy6.anu.edu.au>
Here's my vote for Paul's methods, for what its worth. Quit joggling his
elbow Avery. If you want software that configures itself perfectly every
time, stop writing shell scripts and dust off your C compiler manuals & "git
bizy" :) Linux will probably always involve some RTFM, some bugs, and some
hardware it can't configure without some human intervention. Most software
does, production or otherwise. The bigger advantages of Linux are that when
you have a problem you can post to this list and get _real_ help from the
people who wrote it.
C'Mon dude, it doesn't get much easier than RedHat, unless it's preloaded
on the machine when you buy it...
-James
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, feel free to hit "D" now.]
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > [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.
>
> Aha, but we aren't talking about your ArcNet probe. It can do relatively
> safe read-only type probes, and so it is not an issue here.
>
> > 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.
>
> Fine. I agree, as long as you can autoprobe relatively safely, and it
> doesn't involve any writes to i/o ports. If you can't do the probe
> safely, then it should be disabled by default. Module autoprobing for
> ISA ne2k boards will remain disabled. I will eventually change it so
> that PCI probes are allowed if no i/o is given when insmoding it, as
> that was just an oversight on my part and PCI probes are safe.
>
> Paul.
>
