is copied to the /dev directory with the same ownership and permissions as the les
in /lib/udev/devices.
12.2
Kernel uevents and udev
The required device information is exported by the sysfs le system. For every device
the kernel has detected and initialized, a directory with the device name is created. It
contains attribute les with device-specic properties.
Every time a device is added or removed, the kernel sends a uevent to notify udev of
the change. The udev daemon reads and parses all provided rules from the /etc/
udev/rules.d/*.rules les once at start-up and keeps them in memory. If rules
les are changed, added or removed, the daemon can reload the in-memory representa-
tion of all rules with the command udevadm control reload_rules. This is
also done when running /etc/init.d/boot.udev reload. For more details
on udev rules and their syntax, refer to Section 12.6, “Inuencing Kernel Device Event
Handling with udev Rules” (page 211).
Every received event is matched against the set of provides rules. The rules can add or
change event environment keys, request a specic name for the device node to create,
add symlinks pointing to the node or add programs to run after the device node is cre-
ated. The driver core uevents are received from a kernel netlink socket.
12.3 Drivers, Kernel Modules and
Devices
The kernel bus drivers probe for devices. For every detected device, the kernel creates
an internal device structure while the driver core sends a uevent to the udev daemon.
Bus devices identify themselves by a specially-formatted ID, which tells what kind of
device it is. Usually these IDs consist of vendor and product ID and other subsystem-
specic values. Every bus has its own scheme for these IDs, called MODALIAS. The
kernel takes the device information, composes a MODALIAS ID string from it and sends
that string along with the event. For a USB mouse, it looks like this:
MODALIAS=usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02
208 Reference
