diff --git a/chapter09/udev.xml b/chapter09/udev.xml index 396f2b389..4bcb52dfe 100644 --- a/chapter09/udev.xml +++ b/chapter09/udev.xml @@ -16,23 +16,23 @@ In , we installed the udev - package when eudev + daemon when eudev systemd was built. Before we go into the - details regarding how this works, a brief history of previous methods of + details regarding how udev works, a brief history of previous methods of handling devices is in order. Linux systems in general traditionally used a static device creation method, whereby a great many device nodes were created under /dev (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually existed. This - was typically done via a MAKEDEV script, which contains a + was typically done via a MAKEDEV script, which contained a number of calls to the mknod program with the relevant major and minor device numbers for every possible device that might exist in the world. - Using the udev method, only those devices which are detected by the - kernel get device nodes created for them. Because these device nodes will be - created each time the system boots, they will be stored on a Using the udev method, device nodes are only created for those devices + which are detected by the kernel. These device nodes are + created each time the system boots; they are stored in a devtmpfs file system (a virtual file system that resides entirely in system memory). Device nodes do not require much space, so the memory that is used is negligible. @@ -51,23 +51,23 @@ class="filesystem">devfs was the way it handled device detection, creation, and naming. The latter issue, that of device node naming, was perhaps the most critical. It is generally accepted that if - device names are allowed to be configurable, then the device naming policy - should be up to a system administrator, not imposed on them by any - particular developer(s). The devfs file system also suffered from race - conditions that were inherent in its design and could not be fixed without a - substantial revision to the kernel. It was marked as deprecated for a long - period – due to a lack of maintenance – and was finally removed + conditions that were inherent in its design; these could not be fixed without a + substantial revision of the kernel. devfs + was marked as deprecated for a long + time, and was finally removed from the kernel in June, 2006. With the development of the unstable 2.5 kernel tree, later released as the 2.6 series of stable kernels, a new virtual filesystem called sysfs came to be. The job of - sysfs is to export a view of + sysfs is to provide information about the system's hardware configuration to userspace processes. With this - userspace-visible representation, the possibility of developing a userspace - replacement for devfs became - much more realistic. + userspace-visible representation, it became possible to develop a userspace + replacement for devfs. @@ -81,12 +81,12 @@ was mentioned briefly above. One may wonder how sysfs knows about the devices present on a system and what device numbers should be used for them. Drivers that - have been compiled into the kernel directly register their objects with a + have been compiled into the kernel register their objects in sysfs (devtmpfs internally) - as they are detected by the kernel. For drivers compiled as modules, this - registration will happen when the module is loaded. Once the sysfs filesystem is mounted (on /sys), - data which the drivers register with sysfs are available to userspace processes and to udevd for processing (including modifications to device nodes). @@ -96,13 +96,13 @@ Device Node Creation - Device files are created by the kernel by the devtmpfs filesystem. Any driver that - wishes to register a device node will go through the Device files are created by the kernel in the devtmpfs file system. Any driver that + wishes to register a device node will use the devtmpfs (via the driver core) to do it. When a devtmpfs instance is mounted on /dev, the device node - will initially be created with a fixed name, permissions, and + will initially be exposed to userspace with a fixed name, permissions, and owner. A short time later, the kernel will send a uevent to @@ -172,7 +172,7 @@ creating device nodes. - A kernel module is not loaded automatically + A Kernel Module Is Not Loaded Automatically Udev will only load a module if it has a bus-specific alias and the bus driver properly exports the necessary aliases to - A kernel module is not loaded automatically, and udev is not - intended to load it + A Kernel Module Is Not Loaded Automatically, and Udev Is Not + Intended to Load It If the wrapper module only enhances the functionality provided by some other module (e.g., @@ -236,7 +236,7 @@ - Udev loads some unwanted module + Udev Loads Some Unwanted Module Either don't build the module, or blacklist it in a /etc/modprobe.d/blacklist.conf file as done with the @@ -250,7 +250,7 @@ - Udev creates a device incorrectly, or makes a wrong symlink + Udev Creates a Device Incorrectly, or Makes the Wrong Symlink This usually happens if a rule unexpectedly matches a device. For example, a poorly-written rule can match both a SCSI disk (as desired) @@ -261,7 +261,7 @@ - Udev rule works unreliably + Udev Rule Works Unreliably This may be another manifestation of the previous problem. If not, and your rule uses sysfs @@ -275,15 +275,15 @@ - Udev does not create a device + Udev Does Not Create a Device - Further text assumes that the driver is built statically into the - kernel or already loaded as a module, and that you have already checked - that udev doesn't create a misnamed device. + First, be certain that the driver is built into the + kernel or already loaded as a module, and that + udev isn't creating a misnamed device. - Udev has no information needed to create a device node if a kernel - driver does not export its data to - sysfs. This is most common + If a kernel driver does not export its data to + sysfs, udev lacks the + information needed to create a device node. This is most likely to happen with third party drivers from outside the kernel tree. Create a static device node in /usr/lib/udev/devices with the appropriate major/minor numbers (see the file @@ -295,7 +295,7 @@ - Device naming order changes randomly after rebooting + Device Naming Order Changes Randomly After Rebooting This is due to the fact that udev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will