isapnp does try to get this right:
attempt to determine safe settings to which the
devices can be set, and uncomment those settings in
the output. pnpdump will use the /proc filesystem
and the lspci program to discover system resources
that have already been allocated if these facili-
ties are available on the system.
> (2) Furthermore... Even _if_ the isapnp program does check that a
> resource is not used by a driver when it runs, there is nothing
> to prevent another driver from grabbing the resource between
> isapnp running and the insmod process for the new driver being
> run. For instance, someone could open /dev/fd0, at which point
> the floppy driver wakes up and grabs it's resources (it doesn't
> hold on to them permanently).
An entirely valid point, but only true for ISA devices that don't do PnP.
isapnp should know about even inactive PCI devices and ISA PnP ones.
Kernel configuration management would not help here unfortunately -- you
have to actually run the device probes at boot time to see what port
ranges to avoid.
> The configuration manager I wrote takes this into account, and locks all
> resource management features whilst it:
> (1) negotiates a set of resources for a new driver
> (2) re-negotiates the resources on an old driver
> (3) simply changes the configuration of an unattached device
How does it deal with non-PnP ISA devices whose drivers are not linked
into the kernel, so the probes don't happen when the kernel initialises?
> Additionally:
> * Why should PnP be any different to PCI in handling/maintainance? Or
> PnP-BIOS? Or PCMCIA? Surely the way the driver perceives such things
> should be abstracted from the configuration protocol!
Agree, but bear in mind PCI resources are usually assigned by the BIOS,
and just read by the kernel.
> * Doing the configuration management inside the kernel means that
> drivers can have their resource values changed on the fly without having
> to be reloaded... This isn't as bad as it sounds, it just takes a little
> bit of discipline on the part of the kernel and the driver.
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.
We get by perfectly well without on-the-fly reassignments now; I don't
see a pressing need for it.
-- Jamie
-
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/