> Well we support non-PnP ISA cards which are even more antiquated. I
> dont see any reason why anyone would advocate excluding an entire
> class of hardware simply because they dont like the interface.
I don't think this necessarily includes ISA-PnP though, the interface
might blow goats - but it doesn't make it completely unworkable, its
just the current proposed 100% kernel solutions are inelegant (IMO)
and seem very ISA centric, and don't necessarily have to be 100% done
in the kernel.
> Im not sure how adding PnP support is at the "expense" of sane
> hardware.
No one said it was, _I_ certainly didn't mean that if thats how it
was taken.
All I'm saying is, I don't think the correct solution need penalise
people who don't care much for PnP, obviously, a clean CONFIG option
can do this.
> There should be a halfway approach that would satisfy both camps.
> Eg those who want PnP in monolithic kernels and those who dont want
> to touch PnP with a 10 meter pole.
If _all_ the PnP stuff, including the device database, is in the
kernel, it pretty much precludes the ability of vendor X to ship a
binary only module for PnP hardware, doesn't it?
(insert standard rant about stable module API for anal vendors)
Having a hybrid approach could allow them to do so, by shipping some
kind of definition file that allows the userspace code to init and
setup the hardware with the driver. (I did have a suggestion here on
how to do it, but it would require quite a few changes and also
require lots of the __init code to be moved into the main code
segment - so I don't think its a good suggestion).
Perhaps a more abstracted interface that when the kernel boots in
walks the busses/devices the are available an inits what it finds?
I think the whole device initiation thing needs a bit of a cleanup
anyhow. SCSI cards/disk/etc. appear in seemingly random order (yes, I
know its not truly), different types of Ethernet cards when mixed
appear in different orders, etc. Its a bit of a pain when you have a
box with 5 ISA Ethernet cards, and one dies - so you replace it and
all your Ethernet device numbers get screwed up.
Oh, while I remember, devices/drivers should be able to specific a
`shutdown' so they can turn of devices of halt/reboot. This means
halted kernel will no longer still route packets or respond to pings,
watchdog timers can be stopped cleanly, sound cards silenced, etc.
> Maybe I can twist some arms at Intel labs. :-)
Not likely... I'd love for Intel to release i740 specs, but the
company is overrun by marketroids...
-cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html