MODULE_ALIAS [LWN.net]

The Linux kernel has long had the capability to load modules on demand when external events make their presence necessary. In many cases, the kernel knows exactly which module is required, and can simply ask for it by name. So, for example, the IDE subsystem can call:

    request_module("ide-cd");

should it encounter a CD needing a driver. In many cases, however, the kernel does not know exactly which module should be loaded; in these cases it punts the question into user space. So, for example, if a user program tries to open a block device node with major number 100, and no driver has registered that number, the kernel will try to load a module called block-major-100. The job of finding a module then falls on modprobe, which will expect to find an alias line in /etc/modules.conf telling it what module should really be loaded.

The only problem with this scheme is that device drivers usually already know which device numbers they are prepared to support. Adding configuration information to /etc/modules.conf is, at best, redundant. It can also be misleading; the poor administrator who tries to connect a driver to a different device number via modules.conf is unlikely to experience much joy.

When the new module loader was added - almost one year ago, now - it included a new MODULE_ALIAS macro. The purpose of this macro is to allow driver authors to specify directly which aliases the module should be responsible for. It is an idea that makes sense, but uptake has been slow; a quick grep of the 2.6.0-test4 source shows that there is not a single use of MODULE_ALIAS in the kernel tree.

That situation appears to be about to change, now that Rusty Russell has released a set of patches which insert actual MODULE_ALIAS calls into the kernel source. The actual variants used depend on the subsystem; block drivers use MODULE_ALIAS_BLOCKDEV, for example, while char devices use MODULE_ALIAS_CHARDEV or MODULE_ALIAS_MISCDEV and network protocols use MODULE_ALIAS_NETPROTO.

There are still situations which require alias commands in the modules.conf file: there is no way for a driver author to know which module should be loaded to implement eth0, for example. But many of the boilerplate aliases can be, eventually, removed. Internal alias support has been present in module-init-tools for some time, so all that's needed before the alias commands can be cleaned up is to get rid of all those legacy 2.4 (and prior) kernels.