The reason I put it all in the kernel is so that it was available _before_
the mass storage device drivers and thus filesystems and thus usermode
programs were available.
It presents a unified interface to the drivers, such that they don't need to
know how the hardware is interfaced to the CPU.
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.
I have had my serial, soundcard-sound, soundcard-IDE and normal IDE devices
all reconfigured whilst in use... So it can be done.
> > 2) insmod would then scan module files for "tag tables" which describe the
> > range of devices that a driver can handle (by device ID or by device
> > class), and should it find a suitable module, it would then load it.
> My idea is to leave this to modprobe, with suitable depmod support to
> build an index of IDs (tags) <-> modules. The index may well be just a
> file of aliases, in the form `alias isapnp-DFX0000_1493 serial'.
Well, I did say insmod _(or some similar tool)_ in point (1). How the
configuration manager actually asks a user space loader for a driver, I'm not
too sure about... but I'm sure it can't be all that hard.
However, what do you do for linking more than one device to a module at once?
How does the kernel in your scheme determine that a number of devices should
be attached to one driver (eg: two serial port devices and a modem card)? And
how does hot addition (say by PCMCIA) attach a new device to an already loaded
In my design, each driver description block points at a table of tags that the
cmgr can scan. Should the cmgr find one it likes, it can try attaching to that
driver. Should driver say no, then the cmgr can go on looking for other tags.
Also, the kernel might have to try several variations as some devices can have
more than one tag (such as PnP), or can have classes (such as PCI). These can
be passed all at once, or one at a time depending on the interface.
> > 3) Whilst loading, the module would register it's drivers with the cmgr.
> > 4) The cmgr would then look through the tags tables pointed to by the drivers,
> > and attach devices appropriately.
> > 5) Whilst attaching a device to a driver, the cmgr will negotiate a
> > configuration between the device config interface (PnP, PCI, etc), the
> > driver, and any conflicting devices on the system.
> This is the overly complex part.
> Why not just let a userspace configuration manager decide on appropriate
> settings *before* it loads the module, and pass them at insmod time?
What if it isn't a module?
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).
The drivers themselves have to do very little work.
> I explained my method for this in one of my previous postings.
> If a conflict is detected, and it requires changing some other driver's
> settings, it will probably require shutting down the other driver and
> reloading it in any case. If an irreconcilable conflict is detected...
> Well, it's irreconcilable!
What if the other driver is one you can't do without? An 'irreconcilable'
conflict is, as you say, irreconcilable, and not a lot can be done about it,
by my software, or anyone else's (though maybe the BIOS can).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/faq.html