diff --git a/chapter09/bootscripts.xml b/chapter09/bootscripts.xml index cb88a9fd8..fbffa76df 100644 --- a/chapter09/bootscripts.xml +++ b/chapter09/bootscripts.xml @@ -74,7 +74,7 @@ checkfs Checks the integrity of the file systems before they are mounted - (with the exception of journal and network based file systems) + (with the exception of journaling and network-based file systems) checkfs @@ -173,8 +173,8 @@ mountfs - Mounts all file systems, except ones that are marked - noauto or are network based + Mounts all file systems, except those that are marked + noauto, or are network based mountfs @@ -208,7 +208,7 @@ The master run-level control script; it is responsible for running all the other bootscripts one-by-one, in a sequence determined - by the name of the symbolic links being processed + by the names of the symbolic links to those other bootscripts rc @@ -239,8 +239,8 @@ setclock - Resets the kernel clock to local time in case the hardware clock - is not set to UTC time + Resets the system clock to local time if the hardware clock + is not set to UTC setclock @@ -305,7 +305,7 @@ udev Prepares the /dev - directory and starts Udev + directory and starts the udev daemon udev diff --git a/chapter09/introduction.xml b/chapter09/introduction.xml index da5ffe67c..745ca3165 100644 --- a/chapter09/introduction.xml +++ b/chapter09/introduction.xml @@ -11,19 +11,19 @@ Introduction Booting a Linux system involves several tasks. The process must - mount both virtual and real file systems, initialize devices, activate swap, - check file systems for integrity, mount any swap partitions or files, set + mount both virtual and real file systems, initialize devices, + check file systems for integrity, mount and activate any swap partitions or files, set the system clock, bring up networking, start any daemons required by the - system, and accomplish any other custom tasks needed by the user. This + system, and accomplish any other custom tasks specified by the user. This process must be organized to ensure the tasks are performed in the correct - order but, at the same time, be executed as fast as possible. + order and executed as quickly as possible. System V System V is the classic boot process that has been used in Unix and Unix-like systems such as Linux since about 1983. It consists of a small - program, init, that sets up basic programs such as + program, init, that sets up basic processes such as login (via getty) and runs a script. This script, usually named rc, controls the execution of a set of additional scripts that perform the tasks required to initialize the @@ -31,7 +31,7 @@ The init program is controlled by the /etc/inittab file and is organized into run levels that - can be run by the user. In LFS, they are used as follows: + can be chosen by the user. In LFS, they are used as follows: 0 — halt 1 — Single user mode @@ -70,13 +70,13 @@ Serial processing of boot tasks. This is related to the previous - point. A delay in any process such as a file system check, will + point. A delay in any process, such as a file system check, will delay the entire boot process. Does not directly support advanced features like - control groups (cgroups), and per-user fair share scheduling. + control groups (cgroups) and per-user fair share scheduling. 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