Ignore:
Timestamp:
07/02/2005 05:16:45 PM (19 years ago)
Author:
Archaic <archaic@…>
Branches:
6.1, 6.1.1
Children:
b8a3fb2
Parents:
464fa64f
Message:

Several minor wording changes in chapter 8. (merge from trunk r6318)

git-svn-id: ​http://svn.linuxfromscratch.org/LFS/branches/6.1/BOOK@6336 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

File:
1 edited

Legend:

Unmodified
Added
Removed

  • chapter07/udev.xml

    r464fa64f rb568bbaf  
    1313
    1414<para>In <xref linkend="chapter-building-system"/>, we installed the Udev
    15 package.  Before we go into the details regarding how this works,
     15package. Before we go into the details regarding how this works,
    1616a brief history of previous methods of handling devices is in
    1717order.</para>
    1818
    19 <para>Linux systems in general traditionally use a static device
    20 creation method, whereby a great many device nodes are created under
    21 <filename class="directory">/dev</filename> (sometimes literally
    22 thousands of nodes), regardless of whether the corresponding hardware
    23 devices actually exist. This is typically done via a
    24 <command>MAKEDEV</command> script, which contains a number of
    25 calls to the <command>mknod</command> program with the relevant major and minor device
    26 numbers for every possible device that might exist in the world. Using
    27 the udev method, only those devices which are detected by the kernel
    28 get device nodes created for them. Because these device nodes will be
    29 created each time the system boots, they will be stored on a
    30 <systemitem class="filesystem">tmpfs</systemitem> (a file system that
    31 resides entirely in memory and does not take up any disk space).
    32 Device nodes do not require much disk space, so the memory that is
    33 used is negligible.</para>
     19<para>Linux systems in general traditionally use a static device creation
     20method, whereby a great many device nodes are created under <filename
     21class="directory">/dev</filename> (sometimes literally thousands of nodes),
     22regardless of whether the corresponding hardware devices actually exist. This is
     23typically done via a <command>MAKEDEV</command> script, which contains a number
     24of calls to the <command>mknod</command> program with the relevant major and
     25minor device numbers for every possible device that might exist in the world.
     26Using the Udev method, only those devices which are detected by the kernel get
     27device nodes created for them. Because these device nodes will be created each
     28time the system boots, they will be stored on a <systemitem
     29class="filesystem">tmpfs</systemitem> file system (a virtual file system that
     30resides entirely in system memory). Device nodes do not require much space, so
     31the memory that is used is negligible.</para>
    3432
    3533<sect2>
    … …  
    5553as deprecated due to a lack of recent maintenance.</para>
    5654
    57 <para>With the development of the unstable 2.5 kernel tree, later
    58 released as the 2.6 series of stable kernels, a new virtual filesystem
    59 called <systemitem class="filesystem">sysfs</systemitem> came to be.
    60 The job of <systemitem class="filesystem">sysfs</systemitem> is to
    61 export a view of the system's structure to userspace processes.  With
    62 this userspace visible representation, the possibility of seeing a
    63 userspace replacement for <systemitem
    64 class="filesystem">devfs</systemitem> became much more
     55<para>With the development of the unstable 2.5 kernel tree, later released as
     56the 2.6 series of stable kernels, a new virtual filesystem called <systemitem
     57class="filesystem">sysfs</systemitem> came to be. The job of <systemitem
     58class="filesystem">sysfs</systemitem> is to export a view of the system's
     59hardrware configuration to userspace processes. With this userspace-visible
     60representation, the possibility of seeing a userspace replacement for
     61<systemitem class="filesystem">devfs</systemitem> became much more
    6562realistic.</para>
     63
    6664</sect2>
    6765
    … …  
    6967<title>Udev Implementation</title>
    7068
    71 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem
    72 was mentioned briefly above.  One may wonder how <systemitem
    73 class="filesystem">sysfs</systemitem> knows about the devices present
    74 on a system and what device numbers should be used.  Drivers that
    75 have been compiled into the kernel directly register their objects
    76 with <systemitem class="filesystem">sysfs</systemitem> as they are
    77 detected by the kernel.  For drivers compiled as modules, this will
    78 happen when the module is loaded.  Once the <systemitem
    79 class="filesystem">sysfs</systemitem> filesystem is mounted (on
    80 <filename class="directory">/sys</filename>), data which the
     69<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
     70mentioned briefly above. One may wonder how <systemitem
     71class="filesystem">sysfs</systemitem> knows about the devices present on a
     72system and what device numbers should be used for them. Drivers that have been
     73compiled into the kernel directly register their objects with <systemitem
     74class="filesystem">sysfs</systemitem> as they are detected by the kernel. For
     75drivers compiled as modules, this registration will happen when the module is
     76loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is
     77mounted (on <filename class="directory">/sys</filename>), data which the
    8178built-in drivers registered with <systemitem
    82 class="filesystem">sysfs</systemitem> are available to userspace
    83 processes and to <command>udev</command> for device node creation.</para>
     79class="filesystem">sysfs</systemitem> are available to userspace processes and
     80to <command>udev</command> for device node creation.</para>
    8481
    8582<para>The <command>S10udev</command> initscript takes care of creating these
    86 device nodes when Linux is booted. This script starts with registering
    87 <command>/sbin/udevsend</command> as a hotplug event handler.  Hotplug events
    88 (discussed below) should not be generated during this stage, but
    89 <command>udev</command> is registered just in case they do occur.  The
     83device nodes when Linux is booted. This script starts by registering
     84<command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events
     85(discussed below) are not usually generated during this stage, but
     86<command>udev</command> is registered just in case they do occur. The
    9087<command>udevstart</command> program then walks through the <systemitem
    9188class="filesystem">/sys</systemitem> filesystem and creates devices under
    92 <filename class="directory">/dev</filename> that match the descriptions.  For
     89<filename class="directory">/dev</filename> that match the descriptions. For
    9390example, <filename>/sys/class/tty/vcs/dev</filename> contains the string
    9491<quote>7:0</quote> This string is used by <command>udevstart</command> to create
    9592<filename>/dev/vcs</filename> with major number <emphasis>7</emphasis> and minor
    96 <emphasis>0</emphasis>.  The names and permissions of the nodes created under
     93<emphasis>0</emphasis>. The names and permissions of the nodes created under
    9794the <filename class="directory">/dev</filename> directory are configured
    9895according to the rules specified in the files within the <filename
    … …  
    10299<emphasis>660</emphasis> and ownership to <emphasis>root:root</emphasis>.</para>
    103100
    104 <para>Once the above stage is complete, all devices that were already
    105 present and have compiled-in drivers will be available for use. What
    106 about those devices that have modular drivers?</para>
     101<para>Once the above stage is complete, all devices that were already present
     102and have compiled-in drivers will be available for use. This leads us to the
     103devices that have modular drivers.</para>
    107104
    108105<para>Earlier, we mentioned the concept of a <quote>hotplug event
    109 handler.</quote> When a new device connection is detected by the
    110 kernel, the kernel will generate a hotplug event and look at the file
    111 <filename>/proc/sys/kernel/hotplug</filename> to find out the
    112 userspace program that handles the device's connection.  The
    113 <command>udev</command> initscript registered <command>udevsend</command>
    114 as this handler. When these hotplug events are generated, the kernel
    115 will tell <command>udev</command> to check the <filename
    116 class="directory">/sys</filename> filesystem for the information
     106handler.</quote> When a new device connection is detected by the kernel, the
     107kernel will generate a hotplug event and look at the file
     108<filename>/proc/sys/kernel/hotplug</filename> to determine the userspace program
     109that handles the device's connection. The <command>udev</command> bootscript
     110registered <command>udevsend</command> as this handler. When these hotplug
     111events are generated, the kernel will tell <command>udev</command> to check the
     112<filename class="directory">/sys</filename> filesystem for the information
    117113pertaining to this new device and create the <filename
    118114class="directory">/dev</filename> entry for it.</para>
    119115
    120 <para>This brings us to one problem that exists with
    121 <command>udev</command>, and likewise with <systemitem
    122 class="filesystem">devfs</systemitem> before it. It is commonly
    123 referred to as the <quote>chicken and egg</quote> problem.  Most Linux
    124 distributions handle loading modules via entries in
    125 <filename>/etc/modules.conf</filename>. Access to a device node causes
    126 the appropriate kernel module to load.  With <command>udev</command>,
    127 this method will not work because the device node does not exist until
    128 the module is loaded.  To solve this, the
    129 <command>S05modules</command> bootscript was added to the
     116<para>This brings us to one problem that exists with <command>udev</command>,
     117and likewise with <systemitem class="filesystem">devfs</systemitem> before it.
     118It is commonly referred to as the <quote>chicken and egg</quote> problem. Most
     119Linux distributions handle loading modules via entries in
     120<filename>/etc/modules.conf</filename>. Access to a device node causes the
     121appropriate kernel module to load. With <command>udev</command>, this method
     122will not work because the device node does not exist until the module is loaded.
     123To solve this, the <command>S05modules</command> bootscript was added to the
    130124LFS-Bootscripts package, along with the
    131 <filename>/etc/sysconfig/modules</filename> file.  By
    132 adding module
    133 names to the <filename>modules</filename> file, these modules will be
    134 loaded when the computer is starting up. This allows
    135 <command>udev</command> to detect the devices and create the
    136 appropriate device nodes.</para>
     125<filename>/etc/sysconfig/modules</filename> file. By adding module names to the
     126<filename>modules</filename> file, these modules will be loaded when the
     127computer is starts up. This allows <command>udev</command> to detect the devices
     128and create the appropriate device nodes.</para>
    137129
    138130<para>Note that on slower machines or for drivers that create a lot
    … …  
    168160class="filesystem">sysfs</systemitem>.</para>
    169161   
    170 <para>This is most common with third party drivers from outside the
    171 kernel tree.  These drivers will not end up having their device nodes
    172 created.  Use the
    173 <filename>/etc/sysconfig/createfiles</filename> configuration file to
    174 manually create the devices. Consult the
    175 <filename>devices.txt</filename> file inside the kernel documentation
    176 or the documentation for that driver to find the proper major/minor
    177 numbers.</para>
     162<para>This is most common with third party drivers from outside the kernel tree.
     163Udev will be unable to automatically create device nodes for such drivers. Use
     164the <filename>/etc/sysconfig/createfiles</filename> configuration file to
     165manually create the devices. Consult the <filename>devices.txt</filename> file
     166inside the kernel documentation or the documentation for that driver to find the
     167proper major/minor numbers.</para>
    178168
    179169<para>2) A non-hardware device is required.  This is most common with
Note: See TracChangeset for help on using the changeset viewer.