[RFC] Flat /lib/modules/`uname -r`

From: Keith Owens (kaos@ocs.com.au)
Date: Fri Apr 21 2000 - 19:22:11 EST


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 : Sun Apr 23 2000 - 21:00:20 EST