I'm currently doing less work than usual, as I'm on an experimental remote learning RHCE training course for four hours a day. It's quite interesting, actually.
We touched on kernel modules today, briefly, and I noticed that when looking through the output of 'modinfo', the instructor skipped straight over all those icky 'alias' lines. This reinforces my suspicion that I'm one of the few people who vaguely understand what the heck's going on there. It's actually a rather a) important and b) cool subsystem, so I think it's nice to know about it.
Most of the useful information about modaliases can be found in this excellent article in the Arch wiki. Basically, a modalias is a way of representing important information about hardware attached to the system.
What's not entirely obvious from that page is why this is important to you. It's important because this is how modules get automatically loaded to support your hardware, that's how! That's what those 'alias' lines in the output of modinfo do. Let's look at one:
[root@adam pci0000:00]# modinfo ssb filename: /lib/modules/2.6.29-0.203.rc7.fc11.x86_64/kernel/drivers/ssb/ssb.ko (...) alias: pci:v000014E4d00004329svsdbcsci* (...)
(There's lots, for most modules, there's just one). These are coded into the kernel modules, and updated by the authors each time they add support for another bit of hardware. They take the same format as the actual aliases for bits of hardware, except that * is a wildcard. So that alias means that the 'ssb' module supports any bit of hardware with the PCI ID 14E4:4329 (which is a Broadcom wireless adapter). All the other bits of the modalias are filled in with * to indicate that it doesn't matter what they are.
Let's look at another style. If you look at the output of 'modinfo usb-storage', you'll see quite a lot of lines like this at the top:
Here, we're not caring about the device ID (USB ID in this case) - all the ID fields are wild-carded out. Instead, what's specified are the ic, isc and ip fields, which together identify a class of devices. There's quite a lot of these lines, as I said, which together cover all the 'USB mass storage' class IDs. So, the usb_storage module supports any device which identifies itself as being in the USB mass storage class. (There's some device-specific IDs further down the modinfo output. These are corner cases for broken or quirky hardware, I think.) You'll see similar aliases in, for example, the snd-usb-audio and uvcvideo modules, thanks to USB having standard interfaces for handling audio and video devices, and classes for these devices.
Aliasing a module simply tell the module tools - like modprobe - to poke that module when they're called with the alias. You can just edit /etc/modprobe.conf, add a line:
alias usb_storage foobar
and run 'modprobe foobar', and the usb_storage module will be loaded. Modaliasing takes advantage of this. As we just saw, modules have aliases representing each bit of hardware they support. When udev comes across a hardware device, it simply runs modprobe on the device's modalias. Thanks to the aliases written into the modules (actually, these are dumped into /lib/modules/
uname -r/modules.alias each time 'depmod' is run, they're not read directly from the module files themselves by modprobe), the correct module is automatically loaded.
Well, that's how that works, anyway. I think it's rather elegant.