The state of 2.5 module support

One problem that was the source of much complaining was the requirement that every module provide a module initialization function, or else include an explicit no_module_init line. This "feature" was set to force changes to large numbers of drivers, which were otherwise working just fine. The real purpose behind this requirement was to get the name of the module into the compiled code. Kai Germaschewski came up with a fix that allows the module name to be given at compile time; this fix was merged for 2.5.51.

A separate patch, also merged for 2.5.51, restores the generation of the USB and PCI hotplug tables.

Then, there is the little problem that module parameters do not work. Rusty Russell has been working on this issue for a while, and has produced several sets of patches, none of which have been merged as of this writing. The latest patch creates a new macro for the establishment of module parameters:

    module_param(name, type, perm);

Where name is the name of the local variable to receive the value given for the parameter, type is the type of the variable, and perm is a set of permissions flag that will be used in the future when parameters are exported via sysfs. module_param is slightly misnamed, in that it sets up parameters to be set at module load time, or, for compiled-in code, at boot time. But suggestions for other names (like simply "param") did not pass the Linus test.

There is also a compatibility layer which lets modules using the older MODULE_PARM declarations work until they are updated.

Finally, work continues on the new module tools (which may be found in this directory). These tools provide the usual module functionality, along with a script to convert the standard modules.conf file into the new modprobe.conf format.

Shaking out all of the module issues will doubtless take some time yet. But the worst problems are being solved; soon it will be time to find something else to complain about.