Following are some ideas I've been playing with for enhancing module
support a bit more. These ideas are 2.3 stuff, but I'd like some comments
on them before I'm too deeply coding... Especially from Richard (as I'm
radically changing modutils) and from Alan (as my ideas concern PnP, which
he's mentioned as a 2.3 goal).
So, here goes.
1. Persistence
One of the major pitfalls with current module support is that user
settings are not saved between uses of a module. This includes both
`initialization' settings (set using `parm=xxx' at insmod time) and
runtime-tunable settings (such as sound volume).
To get over this, I suggest a completely user-space approach.
Module settings will be accessed, just prior to module removal, by having
rmmod inspect kernel memory for the relevant variables. It can be done by
having rmmod load the object module, gather the list of variables to
inspect, and access them via /dev/kmem. (BTW, this will mean that we need
to remove the automatic reaping logic from the kernel, and move it to a
userspace daemon; this isn't all that hard, and provides added benefits
like per-module autoremoval timeout. And anything that moves code to
userland is a win...)
The persistence mechanism itself will be implemented by having rmmod save
the settings it's read into some file (probably indexed by module name);
modprobe will consult this file, in addition to /etc/modules.conf, to
determine module parameters when it invokes insmod.
One caveat on this approach is that any state saved must be settable by
insmod parameters; still, I think this is acceptable.
(An aside: i'm not all that sure that rmmod should read the settings
itself; maybe it's a job for another program. This program can then be
used both from the userspace reaping daemon and from the shutdown scripts
to save the state on powerdown).
2. Plug-and-Play support
To properly support PnP, we need a method for userspace `bus managers' to
identify drivers by their IDs on the bus, and to configure them.
To solve the identification problem, I suggest that depmod should be
changed to also print a file mapping the device IDs found inside modules
(specified using the MODULE_SUPPORTED_DEVICE macro) to module names (this
may even be some sort of `aliases' file, in the form `alias
pci-id-1274-1371 es1371' or `alias pcmcia-id-3Com_Corporation-3C589
3c589_cs'). modprobe will be able to map these identifiers to the correct
module.
The configuration problem can be solved, again, without too many problems.
The bus manager should be able to ask modprobe what it's insmod parameters
will be given a specific device id (e.g., `modprobe -q
pcmcia-id-3Com_Corporation-3C589' will get a reply like
`/lib/modules/2.3.11-2/sound/3c589_cs irq=22'). The bus manager will also
use modinfo to get the list of parameters supported by a module; we'll
need to make all modules support uniform names for some parameters, so the
managers will recognize the neccessary ones (like `irq' and `io').
3. Additional modinfo
I suggest to add the following information into each module:
* _All_ modules should have, at least, a MODULE_DESCRIPTION.
* All module parameters should use MODULE_PARM, preferrably together with
MODULE_PARM_DESC. (Also, as mentioned above, common parameters should
have conforming names).
* The MODULE_PARM type syntax should be extended, providing also an
ability for specifying min/max values for integral types (maybe even a
comma-separated list of allowed values) and `hints' as to input format
(e.g., `MODULE_PARM(io,"i 0x378,0x388 : 0x%x")').
Some of these changes are required for implementing my PnP suggestion; the
syntax extension of MODULE_PARM will allow auto-generation of Red Hat's
module-info files (or maybe even replacing their use altogether by using
modinfo in kernelcfg).
------------------
That's all. I think my ideas can make modules even more usable than they
are now; I expect comments...
-az
------------------------+---------------------------------------------
. __ | Phone: 03-5340753 (home), 03-9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900
------------------------+---------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
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.altern.org/andrebalsa/doc/lkml-faq.html