Yet such devices exist.
> 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.
It would help to some extent - it would effectively combine the isapnp and the
request_region(), etc. steps all in a single atomic step.
But you are also right, a sleeping non-PnP device would be invisible to any
configuration manager, whatsoever we might do, though this could be alleviated
by the kernel keeping a record of the device once it is no longer in use.
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.
> 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.
> 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?
> 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... The driver supplies
information about the configuration it's looking for in a table (which could be
discardable), and the manager looks after:
(1) communicating with various configuration protocol drivers (PCI, PnP, etc)
(2) helps bind multiple devices to the driver
(3) the binding of resources (request_region(), request_dma(), etc.)
(4) enables these devices if necessary
(5) helps pass the configuration to the driver
And conversely, the configuration manager helps dissociate drivers and devices
when devices or drivers are removed from the system. It also frees up
resources on behalf of the driver at the point of dissociation, and
deactivates the device if possible.
> We get by perfectly well without on-the-fly reassignments now; I don't
> see a pressing need for it.
*Shrug* Maybe not for the moment, but the algorithm is fairly small and kind
of neat *grin*. However, the rest of it is a good idea IMHO.
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/