lkml.org 
[lkml]   [1999]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [linux-audio-dev] ISA Plug & Play support in kernel
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.058 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site