Following are some ideas I've been playing with for enhancing modulesupport a bit more. These ideas are 2.3 stuff, but I'd like some commentson them before I'm too deeply coding... Especially from Richard (as I'mradically changing modutils) and from Alan (as my ideas concern PnP, whichhe's mentioned as a 2.3 goal).

So, here goes.

1. Persistence

One of the major pitfalls with current module support is that usersettings are not saved between uses of a module. This includes both`initialization' settings (set using `parm=xxx' at insmod time) andruntime-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 havingrmmod inspect kernel memory for the relevant variables. It can be done byhaving rmmod load the object module, gather the list of variables toinspect, and access them via /dev/kmem. (BTW, this will mean that we needto remove the automatic reaping logic from the kernel, and move it to auserspace daemon; this isn't all that hard, and provides added benefitslike per-module autoremoval timeout. And anything that moves code touserland is a win...)

The persistence mechanism itself will be implemented by having rmmod savethe settings it's read into some file (probably indexed by module name);modprobe will consult this file, in addition to /etc/modules.conf, todetermine module parameters when it invokes insmod.

One caveat on this approach is that any state saved must be settable byinsmod parameters; still, I think this is acceptable.

(An aside: i'm not all that sure that rmmod should read the settingsitself; maybe it's a job for another program. This program can then beused both from the userspace reaping daemon and from the shutdown scriptsto save the state on powerdown).

2. Plug-and-Play support

To properly support PnP, we need a method for userspace `bus managers' toidentify drivers by their IDs on the bus, and to configure them.

To solve the identification problem, I suggest that depmod should bechanged to also print a file mapping the device IDs found inside modules(specified using the MODULE_SUPPORTED_DEVICE macro) to module names (thismay even be some sort of `aliases' file, in the form `aliaspci-id-1274-1371 es1371' or `alias pcmcia-id-3Com_Corporation-3C5893c589_cs'). modprobe will be able to map these identifiers to the correctmodule.

The configuration problem can be solved, again, without too many problems. The bus manager should be able to ask modprobe what it's insmod parameterswill be given a specific device id (e.g., `modprobe -qpcmcia-id-3Com_Corporation-3C589' will get a reply like`/lib/modules/2.3.11-2/sound/3c589_cs irq=22'). The bus manager will alsouse modinfo to get the list of parameters supported by a module; we'llneed to make all modules support uniform names for some parameters, so themanagers 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; thesyntax extension of MODULE_PARM will allow auto-generation of Red Hat'smodule-info files (or maybe even replacing their use altogether by usingmodinfo in kernelcfg).

------------------That's all. I think my ideas can make modules even more usable than theyare now; I expect comments...