I have to admit, I didn't consider using romfs in this manner, having only
really thought about it in terms of installation.
One thing I can do though, is attach the irq, dma, timer, etc. drivers to
appropriate PnP-BIOS devices. I do suppose, though, that this isn't really
necessary, since they are unlikely to ever be made configurable from what is
currently assumed.
> > It presents a unified interface to the drivers, such that they don't need
> > to know how the hardware is interfaced to the CPU.
>
> That is a very important thing for long term maintainability, IMO.
As in mine...
> > But it also means that devices _and_ drivers can be reconfigured
> > 'in-flight' as it were. All that is required is that the driver be aware
> > that the configuration can change, and provide a callback so that the
> > configuration manager can update it. This is, however, optional... the
> > driver can be set in stone by the loading process still.
>
> Nice, but not sure there's any real need for this.
Hot swapping? PCMCIA? What happens when you hot-add a device that conflicts
with some other device already installed, but that other device could be
reconfigured elsewhere?
> I expect some devices (not the drivers, but the devices or clones) might get
> upset at having their ports and interrupts reconfigured while they're
> running.
Hmmmm... hard to gauge... but as the rebinding algorithm locks the device with
the driver at the start, the driver has the opportunity to say "busy!", in
which case that device won't take part.
> OTOH, we really could do with shutting down and starting up for ACPI.
I haven't seen much about ACPI.
> > Also, the negotiation for configuration isn't actually that big an
> > algorithm (under 5K), and uses suprisingly little memory for an a normal
> > sort of lashup (a temporary 3K for around 25 devices).
>
> Maybe it is worth having the stuff to scan tables etc. in a module,
> loaded as needed. It can also be linked in as __init/__initdata for the
> initial boot process.
The stuff for associating devices with drivers is actually a very minor part -
the resource management and /proc UI use a lot more.
> Obviously the bare essentials for unloading devices has to be kept around.
> I mean things like the equivalent of pnpdump don't need to be around all the
> time.
True... the UI could be modularised for demand loading.
> The drivers themselves have to do very little work.
>
> Notably, some of the work the currently do can be moved out of the
> drivers to be shared in the configuration manager.
That's the idea.
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/faq.html