Chapter7:Modules
le16_to_cpu(usb_dev->descriptor.idVendor),
le16_to_cpu(usb_dev->descriptor.idProduct),
le16_to_cpu(usb_dev->descriptor.bcdDevice),
usb_dev->descriptor.bDeviceClass,
usb_dev->descriptor.bDeviceSubClass,
usb_dev->descriptor.bDeviceProtocol,
alt->desc.bInterfaceClass,
alt->desc.bInterfaceSubClass,
alt->desc.bInterfaceProtocol));
By comparing the value ofMODALIASagainst the aliases provided by the modules,udevdcan find the
proper module that needs to be inserted. In this case,usb-storageis the right choice because the follow-
ing alias matches the requirements:
wolfgang@meitner>/sbin/modinfo usb-storage
...
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50*
...
The asterisks are placeholders for arbitrary values as in normal regular expressions, and the last part of
the alias (ic08isc06ip50*) is identical with theMODALIASvalue. Thus the alias matches, andudevdcan
insert theusb-storagemodule into the kernel. How doesudevdknow which aliases a given module
has? It relies on the programdepmod, which scans all available modules, extracts the alias information,
and stores them in the text file/lib/modules/2.6.x/modules.alias.
The story, however, has not come to an end here. After the USB mass storage module has been inserted
into the kernel, the block layer recognizes the device and the partitions contained on it. This leads to
another notification.
root@meitner #udevmonitor
...
UDEV [1201129811.890376] add /block/sdc/sdc1 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/block/sdc/sdc1
SUBSYSTEM=block
MINOR=33
MAJOR=8
PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb7/7-4/7-4:1.0/host7/target7:0:0/7:0:0:0
PHYSDEVBUS=scsi
SEQNUM=1837
UDEVD_EVENT=1
DEVTYPE=partition
ID_VENDOR=Kingston
ID_MODEL=DataTraveler_II
ID_REVISION=PMAP
ID_SERIAL=Kingston_DataTraveler_II_5B67040095EB-0:0
ID_SERIAL_SHORT=5B67040095EB
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_PATH=pci-0000:00:1a.7-usb-0:4:1.0-scsi-0:0:0:0
ID_FS_USAGE=filesystem
ID_FS_TYPE=vfat