Messages in this thread | | | Subject | Re: [linux-audio-dev] ISA Plug & Play support in kernel | Date | Tue, 05 Jan 1999 09:19:21 GMT | From | David Howells <> |
| |
> What's the problem with the following approach: > > pnpdump -c > /etc/isapnp.conf > isapnp /etc/isapnp.conf > script.that.parses./etc/isapnp.conf.and.sets.module_parms.in./etc/modules.conf > > which is what I do for my soundcard.
The problem is twofold and fairly simple: (1) I'm not sure that the isapnp program has anything to prevent it from setting one device's resource to the same as a resource used by a second, non-PnP device which has an active driver attached. This situation is extremely bad because although the kernel knows about the used resource, and would prevent the new driver from being able to grab it, the device has _already_ been configured to use it, and so will respond to reads and writes on that port!
(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).
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
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!
* 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.
In other words, I think the kernel needs a configuration management system in the kernel, and to this end I have written one.
All the best, 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/
| |