lkml.org 
[lkml]   [1999]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-audio-dev] ISA Plug & Play support in kernel
On Thu, Jan 07, 1999 at 09:31:16AM +0000, David Howells wrote:
> As for running device probes during boot... this would not be impossible,
> though it may well be unsatisfactory. You could have the device probes as
> discardable code sections (either in the kernel or in modules) that just
> register device records with the configuration manager when their probes
> strike home. The modules would then just be straightforward drivers that
> access the device record for their configuration.

I am rather fond of the above idea. I proposed something similar a few
years ago (before ISA PnP was ubiquitous), but didn't have the time to
work on it.

> > 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?

> It can't know about a device that doesn't support any familiar
> configuration protocol. But when a driver for such a device runs, it
> just asks for a particular set of resources, and the manager moves
> other device configurations out of the way as necessary.

That's not really good enough. Most devices that don't use a
configuration protocol are active even when their driver is not. So
it's absolutely essential that no other device is configured to use the
same port ranges.

> > 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.

> > 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.

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.

> 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.

-- 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/

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