Re: [Strategic] Linux will never master Plug & Play !?

Torsten Duwe (duwe@ns.lst.de)
Thu, 17 Apr 1997 21:05:10 +0200 (MEST)


Linus> Of course, the correct way to handle this these days is to use
Linus> shared PCI interrupts, in which case none of this all matters (nor
Linus> does PnP - devices can just use the interrupt without really being
Linus> aware of each other, as long as they are ready to accept
Linus> "spurious" interrupts).

Who is going to upgrade all those existing ISA boards in the world for free ?

To give you some background:

I know what a decent bus looks like. I knew the M68k/VME bus even back in
'84. It has a Daisy-Chained IACK and dedicated IACK bus cycles...

We here at LST try to make Linux as easy to install as possible. (We were the
first to publish a single-diskette install procedure; you have the conference
CD, approx. 1 year old.) Asking the user to supply values Lose'95 can
determine by itself surely won't increase Linux' reputation.

Linus> However, one reason PnP has not gotten much support from me
Linus> personally is that PnP doesn't really help all that much in the
Linus> general case. Yes, PnP helps _if_ you have all-PnP-aware devices,
Linus> but quite frankly the whole standard is slightly broken and
Linus> superceded by PCI anyway to a large degree. As such I'm not all
Linus> that excited about PnP, especially as trying to be excessively
Linus> PnP-aware has been known to result in problems on systems that are
Linus> _not_ PnP-ready.

Agreed -- these problems must be avoided. But isn't this situation exactly
what "hacker"-kernels are for ? The last one I tried didn't even compile.
As a comparison: _*daily*_snapshots_ of my favorite OS (NetBSD-current) are
more stable than linux-2.1.xx "_releases_" and they have PnP for a growing
number of devices. I definately think it's worth trying.

Linus> The strategic decision _has_ been made: I'm taking a "wait and
Linus> see" approach to PnP. So far, PnP hasn't convinced me.

Did "wait and see" (WnC for short :-) get Linux this far ? No !
You're not getting old, are you ;-) ?

Linus> HOWEVER - don't take this as a final "no" to PnP. I just want to
Linus> make it very clear that I think that some of the issues with PnP
Linus> are essentially dead: the ISA PnP irq stuff being one of them (the
Linus> IRQ's are really an issue only for ISA devices, and when it comes
Linus> to ISA devices the _huge_ majority are totally unaware of PnP).

PnP is not dead ! Try to buy a new soundcard without it ! And what if the
luser has attached his installation CD-ROM drive to it ???

Linus> Other PnP stuff can certainly be worth pursuing (like the
Linus> parallell and serial port PnP autodetection - although even in
Linus> this case I suspect that PnP will be superceded by the USB:
Linus> anything so clever that it responds to PnP queries will probably
Linus> be using USB within the year anyway).

Please note that PnP cards _do_ exist out there, and Linux shouldn't ignore
them, since it already provides drivers for almost each and every little
piece of HW. In fact I've occasionally experienced _worse_ HW support when
installing Lose'95 (only for Duke Nukem playing, of course :-) on some newer
machines !

Linus> In short, I think PnP was too little, too late, and that it hasn't
Linus> caught on enough to worry about it more than we do. I will
Linus> certainly accept PnP-aware patches, but those patches may under
Linus> _no_ circumstances break more important stuff (ie non-PnP
Linus> devices).

All I'm asking for (first step) is a way to determine _all_ occupied
resources the kernel knows about, and not only if the devices in question are
in use. Then an automated algorithm (second step) can determine an assignment
of the remaining resources to PnP cards via isapnp(8) and provide the values
to the non-PnP driver modules of those cards (in-kernel, third step).

Isn't this worth "breaking" the non-working interrupt-sharing-by-handler-
switching ?

Torsten