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

From: Olaf Titz (
Date: Mon Apr 24 2000 - 11:34:23 EST

> * 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).

You'll always find stuff which you can't categorize easily or for
which you have to open a new category. (Where does i2c go?)

> * Separate directories allow third party modules to be added cleanly.
> For example, external PCMCIA installs into modules/.../pcmcia.

As it stands now, they install in misc. This is both when they use
product-specific hacks to configure their Makefiles and when they do
the ugly and dangerous "make modules SUBDIRS=`pwd` -C $KERNEL" trick.

Useless is the best word I have for that.

> * 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.

I'll buy that when we have a useful standard compilation environment for that.

> * Users can tell from the directory what type of module they are
> looking at.

Then the structure needs to be overhauled; many of them are ordered in
the "wrong" place already (af_* stuff, ppp, video, etc.)
The right way to get information about a module is "modinfo" anyway.

> * An explicit list of directories in modprobe gives a guaranteed scan
> order when looking for a module.

We can have that in a simpler way if we skip the whole categories idea
and make it a straight path configuration. (Cf.: not even /bin is
magic to the shell.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST