True, but unless we probe for every possible device as part of the boot
sequence, we have to live with the problem, no matter whether the
configuration is done in user space or kernel space.
However, ESCD or similar can be used to record areas in the BIOS to avoid
conflicts with PCI/PnP as legacy devices are discovered.
> > Agree, but bear in mind PCI resources are usually assigned by the BIOS,
> > > and just read by the kernel.
> >
> > Same for PnP, so why bother with isapnp?
>
> (a) Because unlike PCI, PnP devices often aren't assigned by the BIOS.
> (b) You still need pnpdump to find out what the BIOS assigned, if it did.
(a) Maybe true, but I've only had three BIOS's at home and two at work to go
on.
(b) Or some equivalent kernel API.
> > > I'm not convinced this is a good idea. Asking for extra discipline in the
> > > drivers may well be asking for too much (and possibly code bloat in the
> > > drivers too). And there will be the problem of buggy hardware, that does
> > > not work properly with reassignments.
> >
> > The extra discipline is optional... drivers can still be of the opinion
> > that they should be unloaded for the device to be reconfigured.
> >
> > However, you mention code-bloat... the configuration manager should
> > actually make an inflexible driver's code footprint smaller...
>
> Oh, I agree that generic configuration management would make for smaller
> drivers, and better ones too. And they could run on PCI *and* ISA,
> probably on more platforms etc.
Then at least we agree on something.
> What I mean is the resource reassignment feature could lead to driver
> bloat, if drivers have to keep track of when their resources are
> actually in use and can't be reassigned.
(a) It's optional for the driver
(b) The method by which the driver is initially configured could be re-used.
(c) Things such as open/release functions could just set/clear the flags in
the driver description block.
> > The driver supplies information about the configuration it's looking
> > for in a table (which could be discardable)
>
> That is how I would do it, too. That table could be scanned by `depmod'
> as well as the kernel initialisation code, to search for a module when a
> device is detected as plug-n-play was intended to do.
That was one of my thoughts, but I haven't actually sat down worked out how to
do it yet, but it would involve kerneld or kmod.
This method would also work for hot-swappable technologies (such as PCMCIA) -
you plug in a new device, the PCMCIA interface detects it and tells the
configuration manager about it. This then scans all currently loaded drivers
for one to handle it, and then if not found there, invokes kmod to try and
load a suitable module.
David Howells
-
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.tux.org/lkml/