diff --git a/chapter05/bash.xml b/chapter05/bash.xml index db5d5b4d7..60957b9c1 100644 --- a/chapter05/bash.xml +++ b/chapter05/bash.xml @@ -86,7 +86,7 @@ Make a link for the programs that use sh for a shell: -ln -vs bash /tools/bin/sh +ln -sv bash /tools/bin/sh diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index 0edcd87d2..b7f97a386 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -238,7 +238,7 @@ cd ../gcc-build since that file will end up containing the objects normally contained in libgcc_eh.a: -ln -vs libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&_eh/'` +ln -sv libgcc.a `$LFS_TGT-gcc -print-libgcc-file-name | sed 's/libgcc/&_eh/'` diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml index ee09e026c..9bbca7839 100644 --- a/chapter05/gcc-pass2.xml +++ b/chapter05/gcc-pass2.xml @@ -210,7 +210,7 @@ RANLIB=$LFS_TGT-ranlib \ cc leaves the system administrator free to decide which C compiler to install: -ln -vs gcc /tools/bin/cc +ln -sv gcc /tools/bin/cc At this point, it is imperative to stop and ensure that the basic diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 1d65a221f..b8a8bc8cb 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -76,87 +76,87 @@ Sysfs - The sysfs filesystem was - mentioned briefly above. One may wonder how The sysfs filesystem + 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 - sysfs 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 built-in drivers - registered with sysfs are - available to userspace processes and to udevd for - processing (including modifications to device nodes). - - - - - Udev Bootscripts - - The /etc/rc.d/init.d/udev initscript takes care - of creating device nodes when Linux is booted. The script unsets the - uevent handler from the default of /sbin/hotplug. - This is done because the kernel no longer needs to call out to an - external binary. Instead udevd will listen on a - netlink socket for uevents that the kernel raises. Next, the bootscript - copies any static device nodes that exist in /lib/udev/devices to /dev. This is necessary because some - devices, directories, and symlinks are needed before the dynamic device - handling processes are available during the early stages of booting a - system, or are required by udevd itself. Creating - static device nodes in /lib/udev/devices also provides an easy - workaround for devices that are not supported by the dynamic device - handling infrastructure. The bootscript then starts the Udev daemon, - udevd, which will act on any uevents it receives. - Finally, the bootscript forces the kernel to replay uevents for any - devices that have already been registered and then waits for - udevd to handle them. - - The /etc/rc.d/init.d/udev_retry initscript takes - care of re-triggering events for subsystems whose rules may rely on - filesystems that are not mounted until the mountfs - script is run (in particular, /usr and /var may cause this). This script - runs after the mountfs script, so those rules (if - re-triggered) should succeed the second time around. It is configured - from the /etc/sysconfig/udev_retry file; any words - in this file other than comments are considered subsystem names to - trigger at retry time. (To find the subsystem of a device, use - udevadm info --attribute-walk.) + have been compiled into the kernel directly register their objects with a + 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). Device Node Creation - In recent version of udev, udevd no longer - creates device files in /dev. - Instead, this must be handled in the kernel, by the Device files are created by the kernel by the devtmpfs filesystem. Any driver that wishes to register a device node will go through 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 owner. + will initially be created with a fixed name, permissions, and + owner. A short time later, the kernel will send a uevent to udevd. Based on the rules specified in the files within the /etc/udev/rules.d, /lib/udev/rules.d, and /run/udev/rules.d directories, - udevd will create additional symlinks to the device node, - or change its permissions, owner, or group, or modify the internal - udevd database entry for that object. + udevd will create additional symlinks to the device node, or + change its permissions, owner, or group, or modify the internal + udevd database entry (name) for that object. The rules in these three directories are numbered in a similar - fashion to the LFS-Bootscripts package, and all three directories are + fashion to the LFS-Bootscripts package and all three directories are merged together. If udevd can't find a rule for the device it is creating, it will leave the permissions and ownership at whatever devtmpfs used - initially. + initially. + + + Udev Bootscripts + + The first LFS bootscript, + /etc/init.d/mountvirtfs will copy any devices + located in /lib/udev/devices to + /dev. This is necessary because + some devices, directories, and symlinks are needed before the dynamic + device handling processes are available during the early stages of + booting a system, or are required by udevd itself. + Creating static device nodes in /lib/udev/devices also provides an easy + workaround for devices that are not supported by the dynamic device + handling infrastructure. + + The /etc/rc.d/init.d/udev initscript starts + udevd, triggers any "coldplug" devices that have + already been created by the kernel and waits for any rules to complete. + The script also unsets the uevent handler from the default of + /sbin/hotplug . This is done because the kernel no + longer needs to call out to an external binary. Instead + udevd will listen on a netlink socket for uevents that + the kernel raises. + + The /etc/rc.d/init.d/udev_retry initscript takes + care of re-triggering events for subsystems whose rules may rely on + filesystems that are not mounted until the mountfs + script is run (in particular, /usr + and /var may cause this). This + script runs after the mountfs script, so those rules + (if re-triggered) should succeed the second time around. It is + configured from the /etc/sysconfig/udev_retry file; + any words in this file other than comments are considered subsystem names + to trigger at retry time. To find the subsystem of a device, use + udevadm info --attribute-walk <device> where + <device> is a an absolure path in /dev or /sys such as /dev/sr0 or + /sys/class/rtc. @@ -368,12 +368,13 @@ +