From ebecd08c0582ef9c01f784452f87f3a39cf40cdd Mon Sep 17 00:00:00 2001 From: David Bryant Date: Wed, 16 Nov 2022 13:15:01 -0600 Subject: Corrected grammar, spelling, and idiom in chapter 7. --- chapter07/kernfs.xml | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'chapter07/kernfs.xml') diff --git a/chapter07/kernfs.xml b/chapter07/kernfs.xml index 3e96bee5e..48826d06c 100644 --- a/chapter07/kernfs.xml +++ b/chapter07/kernfs.xml @@ -15,13 +15,13 @@ Applications running in user space utilize various file - systems exported by the kernel to communicate + systems created by the kernel to communicate with the kernel itself. These file systems are virtual: no disk - space is used for them. The content of the file systems resides in + space is used for them. The content of these file systems resides in memory. These file systems must be mounted in the $LFS directory tree so the applications can find them in the chroot environment. - Begin by creating directories on which the file systems will be + Begin by creating the directories on which these virtual file systems will be mounted: mkdir -pv $LFS/{dev,proc,sys,run} @@ -29,31 +29,31 @@ Mounting and Populating /dev - During a normal boot of the LFS system, the kernel automatically + During a normal boot of an LFS system, the kernel automatically mounts the devtmpfs - filesystem on the + file system on the /dev directory; the kernel - creates device nodes on that virtual filesystem during the boot process + creates device nodes on that virtual file system during the boot process, or when a device is first detected or accessed. The udev daemon may - change the owner or permission of the device nodes created by the - kernel, or create new device nodes or symlinks to ease the work of - distro maintainers or system administrators. (See + change the ownership or permissions of the device nodes created by the + kernel, and create new device nodes or symlinks, to ease the work of + distro maintainers and system administrators. (See for details.) If the host kernel supports &devtmpfs;, we can simply mount a &devtmpfs; at $LFS/dev and rely - on the kernel to populate it (the LFS building process does not need - the additional work onto &devtmpfs; by udev daemon). - - But, some host kernels may lack &devtmpfs; support and these - host distros maintain the content of - /dev with different methods. - So the only host-agnostic way for populating - $LFS/dev is - bind mounting the host system's + on the kernel to populate it (i.e., the udev daemon will do the + necessary work automatically). + + But some host kernels lack &devtmpfs; support; these + host distros use different methods to create the content of + /dev. + So the only host-agnostic way to populate the + $LFS/dev directory is + by bind mounting the host system's /dev directory. A bind mount is - a special type of mount that allows you to create a mirror of a + a special type of mount that generates a duplicate copy of a directory or mount point at some other location. Use the following - command to do this: + command to do this. mount -v --bind /dev $LFS/dev @@ -62,7 +62,7 @@ Mounting Virtual Kernel File Systems - Now mount the remaining virtual kernel filesystems: + Now mount the remaining virtual kernel file systems: mount -v --bind /dev/pts $LFS/dev/pts mount -vt proc proc $LFS/proc -- cgit v1.2.3-54-g00ecf