The segregation of modules into separate subdirectories under
/lib/modules/`uname -r` has pros and cons.
Pros.
* Categorization of modules picks up incorrectly assigned modules in
the Makefiles. Anything not listed in linux/modules/NAME is stored
in modules/.../misc. In an ideal world there should be nothing in
misc. af_packet, sunrpc and netlink_dev would be in net, lp and
parport would be in char (new).
* Separate directories allow third party modules to be added cleanly.
For example, external PCMCIA installs into modules/.../pcmcia.
* Separation prevents name space collisions between kernel and third
party modules. There can be no name space collisions within kernel
modules because linux/modules is already flat but there can be
conflicts with third party code.
* Users can tell from the directory what type of module they are
looking at.
* An explicit list of directories in modprobe gives a guaranteed scan
order when looking for a module.
Cons.
* modprobe needs to be updated whenever a new /lib/modules/`uname -r`
directory is added or third party code is installed.
* Users have to hunt through subdirectories for modules.
* New directories need changes to Makefile as well as sub Makefiles.
* A user can recompile a kernel to switch code from module to
builtin. If they do not change the value of `uname -r` and forget
to erase the old /lib/modules/`uname -r` contents, they end up with
obsolete modules. This leads to code that is built into the kernel
but still exists as a module, if the old module is loaded it tends
to crash the kernel.
All things considered, the cons outweigh the pros. In particular the
need to update user space (modprobe) whenever a new modules/...
directory is added is annoying and guarantees version skew.
I suggest :-
(1) Store all kernel modules in /lib/modules/`uname -r`/kernel.
(2) modutils looks for modules/.../kernel first, then the old names
(block, ide, usb etc.) then all directories.
(3) make modules_install erases everything in modules/.../kernel before
installing the new modules.
That preserves most of the pros. The only one we lose is "Users can
tell from the directory what type of module they are looking at".
Given the number of modules that are not currently categorized, I can
live with that.
This method preserves backward compatibility, automatically scans all
new subdirectories without user space changes and guarantees that the
installed kernel modules will match your latest compile.
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 21 2000 - 20:29:49 EDT