Johannes Erdfelt wrote:
> > There will need to be some unified approach...or at least it will make lost of
> > things easier.
> > That is why i was talking about a table with devices, and a table with
> > available drivers. If a device is added, the driver table can be searched and
> > we can do something like a fake modprobe (if it is already loaded). If made
> > flexible enough, this can be used for any kind of bus and also solves the
> > problem of hot-plugging busses in other busses.
> > Lists of available drivers can be generated with (foir example) 'modprobe
> > -a'. This requires that the modules contain what device(s) the module
I meant 'depmod -a', off course.
> > supports. (and only has to be run when a driver is added.)
> > I wish I had time...*grin*
>
> I've been favoring a solution with a config file which lists devices and
> the driver. This is because of the chicken and the egg problem with
> modules.
>
> Or were you talking about extracting the device information from the
> module?
Exactly.
The module utilities already parse symbols in the drivers/modules
anyway, it should not be too difficult to have it extract the values of
a(n array of) structure(s).
The information can be stored in a file and read by a userlevel daemon
or stored immediatly in the kernel by depmod (for example, but AFAICS
depmod is best suitable to gather this info.)
Modules can then be loaded by that userlevel daemon or the kernel
itself. (I think the userspace solution has greater flexibility though.)
The modules will have to be adjusted for this system, for example, they
must register their 'probe' function on insertion. (This probe() can be
given a void * with bus specific data.) This allows the dispatcher to
instantiate a new copy of the driver if it is already running.
The details need some work, but i am convinced this can work very well.
In the end this will give us an easy to maintain system (all module
handling becomes generic) which is highly modular, flexible towards the
future and has no problems with stacking busses.
No messing about with driver/device bindigs, the driver carries this
information itself.
This limits adding a driver to copying a file in a modules/*/ directory
and running depmod.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
