Changeset ae20451


Ignore:
Timestamp:
02/08/2006 08:17:00 PM (18 years ago)
Author:
Matthew Burgess <matthew@…>
Children:
5e9d88c
Parents:
ad2c960
Message:

Rewrite most of the Udev explanatory material to reflect the new hotplug-less configuration

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

Files:
3 edited

Legend:

Unmodified
Added
Removed

  • chapter01/changelog.xml

    rad2c960 rae20451  
    3636    </listitem>
    3737-->
     38
     39    <listitem>
     40      <para>February 8, 2006</para>
     41      <itemizedlist>
     42        <listitem>
     43          <para>[matthew] - Rewrite the majority of chapter07/udev.xml to
     44          reflect the new configuration for handling dynamic device naming and
     45          module loading.</para>
     46        </listitem>
     47      </itemizedlist>
     48    </listitem>
    3849
    3950    <listitem>

  • chapter07/udev.xml

    rad2c960 rae20451  
    2424  method, whereby a great many device nodes are created under <filename
    2525  class="directory">/dev</filename> (sometimes literally thousands of nodes),
    26   regardless of whether the corresponding hardware devices actually exist. This is
    27   typically done via a <command>MAKEDEV</command> script, which contains a number
    28   of calls to the <command>mknod</command> program with the relevant major and
    29   minor device numbers for every possible device that might exist in the world.
    30   Using the Udev method, only those devices which are detected by the kernel get
    31   device nodes created for them. Because these device nodes will be created each
    32   time the system boots, they will be stored on a <systemitem
     26  regardless of whether the corresponding hardware devices actually exist. This
     27  is typically done via a <command>MAKEDEV</command> script, which contains a
     28  number of calls to the <command>mknod</command> program with the relevant
     29  major and minor device numbers for every possible device that might exist in
     30  the world.</para>
     31
     32  <para>Using the Udev method, only those devices which are detected by the
     33  kernel get device nodes created for them. Because these device nodes will be
     34  created each time the system boots, they will be stored on a <systemitem
    3335  class="filesystem">tmpfs</systemitem> file system (a virtual file system that
    3436  resides entirely in system memory). Device nodes do not require much space, so
    … …  
    5153    device names are allowed to be configurable, then the device naming policy
    5254    should be up to a system administrator, not imposed on them by any
    53     particular developer(s). The <systemitem class="filesystem">devfs</systemitem>
    54     file system also suffers from race conditions that are inherent in its design
    55     and cannot be fixed without a substantial revision to the kernel. It has also
    56     been marked as deprecated due to a lack of recent maintenance.</para>
    57 
    58     <para>With the development of the unstable 2.5 kernel tree, later released as
    59     the 2.6 series of stable kernels, a new virtual filesystem called <systemitem
    60     class="filesystem">sysfs</systemitem> came to be. The job of <systemitem
    61     class="filesystem">sysfs</systemitem> is to export a view of the system's
    62     hardrware configuration to userspace processes. With this userspace-visible
    63     representation, the possibility of seeing a userspace replacement for
    64     <systemitem class="filesystem">devfs</systemitem> became much more
    65     realistic.</para>
     55    particular developer(s). The <systemitem
     56    class="filesystem">devfs</systemitem> file system also suffers from race
     57    conditions that are inherent in its design and cannot be fixed without a
     58    substantial revision to the kernel. It has also been marked as deprecated
     59    due to a lack of recent maintenance.</para>
     60
     61    <para>With the development of the unstable 2.5 kernel tree, later released
     62    as the 2.6 series of stable kernels, a new virtual filesystem called
     63    <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
     64    <systemitem class="filesystem">sysfs</systemitem> is to export a view of
     65    the system's hardrware configuration to userspace processes. With this
     66    userspace-visible representation, the possibility of seeing a userspace
     67    replacement for <systemitem class="filesystem">devfs</systemitem> became
     68    much more realistic.</para>
    6669
    6770  </sect2>
    … …  
    7073    <title>Udev Implementation</title>
    7174
    72     <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
    73     mentioned briefly above. One may wonder how <systemitem
    74     class="filesystem">sysfs</systemitem> knows about the devices present on
    75     a system and what device numbers should be used for them. Drivers that have
    76     been compiled into the kernel directly register their objects with
    77     <systemitem class="filesystem">sysfs</systemitem> as they are detected by
    78     the kernel. For drivers compiled as modules, this registration will happen
    79     when the module is loaded. Once the <systemitem
    80     class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
    81     class="directory">/sys</filename>), data which the built-in drivers
    82     registered with <systemitem class="filesystem">sysfs</systemitem> are
    83     available to userspace processes and to <command>udev</command> for device
    84     node creation.</para>
    85 
    86     <para>The <command>S10udev</command> initscript takes care of creating
    87     these device nodes when Linux is booted. This script starts by registering
    88     <command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events
    89     (discussed below) are not usually generated during this stage, but
    90     <command>udev</command> is registered just in case they do occur. The
    91     <command>udevstart</command> program then walks through the <systemitem
    92     class="filesystem">/sys</systemitem> filesystem and creates devices under
    93     <filename class="directory">/dev</filename> that match the descriptions.
    94     For example, <filename>/sys/class/tty/vcs/dev</filename> contains the
    95     string <quote>7:0</quote> This string is used by <command>udevstart</command>
    96     to create <filename>/dev/vcs</filename> with major number
    97     <emphasis>7</emphasis> and minor <emphasis>0</emphasis>. The names and
    98     permissions of the nodes created under the <filename
    99     class="directory">/dev</filename> directory are configured according to the
    100     rules specified in the files within the <filename
    101     class="directory">/etc/udev/rules.d/</filename> directory. These are
    102     numbered in a similar fashion to the LFS-Bootscripts package. If
    103     <command>udev</command> can't find a rule for the device it is creating,
    104     it will default permissions to <emphasis>660</emphasis> and ownership to
    105     <emphasis>root:root</emphasis>.</para>
    106 
    107     <para>Once the above stage is complete, all devices that were already present
    108     and have compiled-in drivers will be available for use. This leads us to the
    109     devices that have modular drivers.</para>
    110 
    111     <para>Earlier, we mentioned the concept of a <quote>hotplug event
    112     handler.</quote> When a new device connection is detected by the kernel,
    113     the kernel will generate a hotplug event and look at the file
    114     <filename>/proc/sys/kernel/hotplug</filename> to determine the userspace
    115     program that handles the device's connection. The <command>udev</command>
    116     bootscript registered <command>udevsend</command> as this handler. When
    117     these hotplug events are generated, the kernel will tell
    118     <command>udev</command> to check the <filename
    119     class="directory">/sys</filename> filesystem for the information pertaining
    120     to this new device and create the <filename class="directory">/dev</filename>
    121     entry for it.</para>
    122 
    123     <para>This brings us to one problem that exists with <command>udev</command>,
    124     and likewise with <systemitem class="filesystem">devfs</systemitem> before it.
    125     It is commonly referred to as the <quote>chicken and egg</quote> problem. Most
    126     Linux distributions handle loading modules via entries in
    127     <filename>/etc/modules.conf</filename>. Access to a device node causes the
    128     appropriate kernel module to load. With <command>udev</command>, this method
    129     will not work because the device node does not exist until the module is loaded.
    130     To solve this, the <command>S05modules</command> bootscript was added to the
    131     LFS-Bootscripts package, along with the
    132     <filename>/etc/sysconfig/modules</filename> file. By adding module names to the
    133     <filename>modules</filename> file, these modules will be loaded when the
    134     computer starts up. This allows <command>udev</command> to detect the devices
    135     and create the appropriate device nodes.</para>
    136 
    137     <para>Note that on slower machines or for drivers that create a lot of device
    138     nodes, the process of creating devices may take a few seconds to complete.
    139     This means that some device nodes may not be immediately accessible.</para>
    140 
    141   </sect2>
    142 
    143   <sect2>
    144     <title>Handling Hotpluggable/Dynamic Devices</title>
    145 
    146     <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
    147     player, the kernel recognizes that the device is now connected and generates
    148     a hotplug event. If the driver is already loaded (either because it was
    149     compiled into the kernel or because it was loaded via the
    150     <command>S05modules</command> bootscript), <command>udev</command> will be
    151     called upon to create the relevant device node(s) according to the
    152     <systemitem class="filesystem">sysfs</systemitem> data available in
    153     <filename class="directory">/sys</filename>.</para>
    154 
    155     <para>If the driver for the just plugged in device is available as a module but
    156     currently unloaded, the Hotplug package will load the appropriate module
    157     and make this device available by creating the device node(s) for it.</para>
     75    <sect3>
     76      <title>Sysfs</title>
     77
     78      <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was
     79      mentioned briefly above. One may wonder how <systemitem
     80      class="filesystem">sysfs</systemitem> knows about the devices present on
     81      a system and what device numbers should be used for them. Drivers that
     82      have been compiled into the kernel directly register their objects with
     83      <systemitem class="filesystem">sysfs</systemitem> as they are detected by
     84      the kernel. For drivers compiled as modules, this registration will happen
     85      when the module is loaded. Once the <systemitem
     86      class="filesystem">sysfs</systemitem> filesystem is mounted (on <filename
     87      class="directory">/sys</filename>), data which the built-in drivers
     88      registered with <systemitem class="filesystem">sysfs</systemitem> are
     89      available to userspace processes and to <command>udev</command> for device
     90      node creation.</para>
     91    </sect3>
     92
     93    <sect3>
     94      <title>Udev Bootscript</title>
     95
     96      <para>The <command>S10udev</command> initscript takes care of creating
     97      device nodes when Linux is booted. The script starts by unsetting the
     98      hotplug event handler from the default of <command>/sbin/hotplug</command>
     99      This is done because, instead of the kernel calling out to an external
     100      binary, <command>udev</command> will listen on a netlink socket for
     101      hotplug events that the kernel raises. The bootscript copies any static
     102      device nodes that exist in <filename
     103      class="directory">/lib/udev/devices</filename> to <filename
     104      class="directory">/dev</filename>. This is necessary because some devices
     105      are needed before the dynamic device handling processes are available
     106      during the early stages of booting a system.  Creating static device nodes
     107      in <filename class="directory">/lib/udev/devices</filename> also provides
     108      an easy workaround for devices that are not supported by the dynamic
     109      device handling infrastructure.  The bootscript then starts the Udev
     110      daemon, <command>udevd</command>, which will act on any hotplug events it
     111      receives. Finally, the bootscript &quot;coldplugs&quot; any devices that
     112      have already been registered with the kernel by forcing them to raise
     113      hotplug events which <command>udevd</command> will then handle.</para>
     114    </sect3>
     115
     116    <sect3>
     117      <title>Device Node Creation</title>
     118
     119      <para>To obtain the right major and minor number for a device, Udev relies
     120      on the information provided by <systemitem
     121      class="filesystem">sysfs</systemitem> in <filename
     122      class="directory">/sys</filename>.  For example,
     123      <filename>/sys/class/tty/vcs/dev</filename> contains the string
     124      <quote>7:0</quote>. This string is used by <command>udevd</command>
     125      to create a device node with major number <emphasis>7</emphasis> and minor
     126      <emphasis>0</emphasis>. The names and permissions of the nodes created
     127      under the <filename class="directory">/dev</filename> directory are
     128      determined by rules specified in the files within the <filename
     129      class="directory">/etc/udev/rules.d/</filename> directory. These are
     130      numbered in a similar fashion to the LFS-Bootscripts package. If
     131      <command>udevd</command> can't find a rule for the device it is creating,
     132      it will default permissions to <emphasis>660</emphasis> and ownership to
     133      <emphasis>root:root</emphasis>. Documentation on the syntax of the Udev
     134      rules configuration files are available in
     135      <filename>/usr/share/doc/udev-084/index.html</filename></para>
     136    </sect3>
     137
     138    <sect3>
     139      <title>Module Loading</title>
     140
     141      <para>If a device driver has been compiled as a module, the rules that
     142      LFS installs will cause <command>udevd</command> to call out to
     143      <command>/sbin/modprobe</command> with the name of the corresponding
     144      module, thereby loading the driver.</para>
     145    </sect3>
     146
     147    <sect3>
     148      <title>Handling Hotpluggable/Dynamic Devices</title>
     149
     150      <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
     151      player, the kernel recognizes that the device is now connected and
     152      generates a hotplug event. This hotplug event is then handled by
     153      <command>udevd</command> as described above.</para>
     154    </sect3>
     155
     156    <!-- FIXME: These are questions Matt thought of while rewriting this page
     157         to reflect the hotplug-less setup but didn't have time to investigate
     158         straight away.
     159    <sect3>
     160      <title>Questions?</title>
     161
     162      <para>7.4.2.3: Are default ownership/permissions still 0660 root:root?  I
     163      thought they'd changed, but can't be sure. Running without a config file
     164      will prove this pretty quickly.</para>
     165
     166      <para>7.4.2.4: How does <command>udevd</command> know which driver to
     167      load, i.e. the correct module name?  Is it in the hotplug event?  I don't
     168      think it can be in /sys as that won't be populated yet (it's the driver
     169      itself that populates /sys, after all).</para>
     170
     171      <para>Is the S05modules script still required?  If so, what are the use
     172      cases for it?</para>
     173
     174    </sect3> -->
    158175
    159176  </sect2>
    … …  
    170187    <para>This is most common with third party drivers from outside the kernel
    171188    tree. Udev will be unable to automatically create device nodes for such
    172     drivers. Use the <filename>/etc/sysconfig/createfiles</filename>
    173     configuration file to manually create the devices. Consult the
    174     <filename>devices.txt</filename> file inside the kernel documentation or
    175     the documentation for that driver to find the proper major/minor
    176     numbers.</para>
     189    drivers. Create a static device node in
     190    <filename>/lib/udev/devices</filename> with the appropriate major/minor
     191    numbers (see the file <filename>devices.txt</filename> inside the kernel
     192    documentation or the documentation provided by the third party driver
     193    vendor). The static device node will be copied to
     194    <filename class="directory">/dev</filename> by the
     195    <command>S10udev</command> bootscript.</para>
    177196
    178197    <para>2) A non-hardware device is required.  This is most common with

  • general.ent

    rad2c960 rae20451  
    11<?xml version="1.0" encoding="ISO-8859-1"?>
    2 <!ENTITY version "Udev_update-20060207">
    3 <!ENTITY releasedate "February 7, 2006">
     2<!ENTITY version "Udev_update-20060208">
     3<!ENTITY releasedate "February 8, 2006">
    44<!ENTITY milestone "6.2">
    55<!ENTITY generic-version "development"> <!-- Use "development", "testing", or "x.y[-pre{x}]" -->
Note: See TracChangeset for help on using the changeset viewer.