Changeset d46b6ed


Ignore:
Timestamp:
May 21, 2014, 4:34:11 PM (10 years ago)
Author:
Chris Staub <chris@…>
Branches:
clfs-3.0.0-systemd, master, systemd
Children:
9224712
Parents:
fab5058
Message:

Rewrote Udev page

Location:
BOOK
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • BOOK/introduction/common/changelog.xml

    rfab5058 rd46b6ed  
    3838
    3939    <listitem>
     40      <para>21 May 2014</para>
     41      <itemizedlist>
     42        <listitem>
     43          <para>[Chris] - Rewrote Udev page in system-config section.</para>
     44        </listitem>
     45      </itemizedlist>
     46    </listitem>
     47
     48    <listitem>
    4049      <para>19 May 2014</para>
    4150      <itemizedlist>

  • BOOK/system-config/common/udev.xml

    rfab5058 rd46b6ed  
    1212
    1313  <indexterm zone="ch-scripts-udev">
    14     <primary sortas="a-systemd">Systemd</primary>
    15     <secondary>udev usage</secondary>
     14    <primary sortas="a-Udev">Udev</primary>
     15    <secondary>usage</secondary>
    1616  </indexterm>
    1717
    18   <para>In <xref linkend="chapter-building-system"/>, we installed systemd,
    19   which contains systemd-udevd, previously known as Udev. Before we go into
    20   the details regarding how this works, a brief history of previous methods of
    21   handling devices is in order.</para>
    22 
    23   <para>Linux systems in general traditionally use a static device creation
    24   method, whereby a great many device nodes are created under <filename
    25   class="directory">/dev</filename> (sometimes literally thousands of nodes),
    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
    35   class="filesystem">tmpfs</systemitem> file system (a virtual file system that
    36   resides entirely in system memory). Device nodes do not require much space, so
    37   the memory that is used is negligible.</para>
     18  <para>In <xref linkend="chapter-building-system"/>, we installed Udev,
     19  as one of the components of systemd. Before we go into the details regarding
     20  how this works, a brief history of previous methods of handling devices is in
     21  order.</para>
    3822
    3923  <sect2>
    4024    <title>History</title>
    4125
    42     <para>In February 2000, a new filesystem called <systemitem
    43     class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
    44     and was made available during the 2.4 series of stable kernels. Although
    45     it was present in the kernel source itself, this method of creating devices
    46     dynamically never received overwhelming support from the core kernel
    47     developers.</para>
    48 
    49     <para>The main problem with the approach adopted by <systemitem
    50     class="filesystem">devfs</systemitem> was the way it handled device
    51     detection, creation, and naming. The latter issue, that of device node
    52     naming, was perhaps the most critical. It is generally accepted that if
    53     device names are allowed to be configurable, then the device naming policy
    54     should be up to a system administrator, not imposed on them by any
    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 hardware 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>
    69 
    70   </sect2>
    71 
    72   <sect2>
    73     <title>Udev Implementation</title>
     26    <sect3>
     27      <title>Static Device Nodes</title>
     28
     29      <para>Linux systems in general traditionally use a static device creation
     30      method, whereby a great many device nodes are created under <filename
     31      class="directory">/dev</filename> (sometimes literally thousands of nodes),
     32      regardless of whether the corresponding hardware devices actually exist.
     33      This is typically done via a <command>MAKEDEV</command> script, which
     34      contains a number of calls to the <command>mknod</command> program with the
     35      relevant major and minor device numbers for every possible device that
     36      might exist in the world.</para>
     37
     38    </sect3>
     39
     40    <sect3>
     41      <title>Devfs</title>
     42
     43      <para>In February 2000, a new filesystem called <systemitem
     44      class="filesystem">devfs</systemitem> was merged into the 2.3.46 kernel
     45      and was made available during the 2.4 series of stable kernels. Although
     46      it was present in the kernel source itself, this method of creating devices
     47      dynamically never received overwhelming support from the core kernel
     48      developers.</para>
     49
     50      <para>The main problem with the approach adopted by <systemitem
     51      class="filesystem">devfs</systemitem> was the way it handled device
     52      detection, creation, and naming. The latter issue, that of device node
     53      naming, was perhaps the most critical. It is generally accepted that if
     54      device names are allowed to be configurable, then the device naming policy
     55      should be up to a system administrator, not imposed on them by any
     56      particular developer(s). The <systemitem
     57      class="filesystem">devfs</systemitem> file system also suffered from race
     58      conditions that were inherent in its design and could not be fixed without a
     59      substantial revision to the kernel. It was marked deprecated with the
     60      release of the 2.6 kernel series, and was removed entirely as of version
     61      2.6.18.</para>
     62
     63    </sect3>
    7464
    7565    <sect3>
    7666      <title>Sysfs</title>
    7767
    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
     68      <para>With the development of the unstable 2.5 kernel tree, later released
     69      as the 2.6 series of stable kernels, a new virtual filesystem called
     70      <systemitem class="filesystem">sysfs</systemitem> came to be. The job of
     71      <systemitem class="filesystem">sysfs</systemitem> is to export a view of
     72      the system's hardware configuration to userspace processes. Drivers that
    8273      have been compiled into the kernel directly register their objects with
    8374      <systemitem class="filesystem">sysfs</systemitem> as they are detected by
    … …  
    8778      class="directory">/sys</filename>), data which the built-in drivers
    8879      registered with <systemitem class="filesystem">sysfs</systemitem> are
    89       available to userspace processes and to <command>udevd</command> for device
    90       node creation.</para>
    91 
    92     </sect3>
    93 
    94     <sect3>
    95       <title>Device Node Creation</title>
    96 
    97       <para>To obtain the right major and minor number for a device, Udev relies
    98       on the information provided by <systemitem
    99       class="filesystem">sysfs</systemitem> in <filename
    100       class="directory">/sys</filename>.  For example,
     80      available to userspace processes. With this
     81      userspace-visible representation, the possibility of seeing a userspace
     82      replacement for <systemitem class="filesystem">devfs</systemitem> became
     83      much more realistic.</para>
     84
     85    </sect3>
     86
     87    <sect3>
     88      <title>Udev Implementation</title>
     89
     90<!--      <title>Device Node Creation</title> -->
     91
     92      <para>When Udev was introduced, the <command>udevd</command> daemon made
     93      calls to mknod() to create device nodes in
     94      <filename class="directory">/dev</filename> dynamically, based on the
     95      information from <systemitem class="filesystem">sysfs</systemitem>, in
     96      <filename class="directory">/sys</filename>. For example,
    10197      <filename>/sys/class/tty/vcs/dev</filename> contains the string
    102       <quote>7:0</quote>. This string is used by <command>udevd</command>
    103       to create a device node with major number <emphasis>7</emphasis> and minor
    104       <emphasis>0</emphasis>. The names and permissions of the nodes created
    105       under the <filename class="directory">/dev</filename> directory are
    106       determined by rules specified in the files within the
    107       <filename class="directory">/lib/udev/rules.d</filename> and <filename
    108       class="directory">/etc/udev/rules.d/</filename> directories. These files
    109       have names that start with numbers, and are evaluated in numerical order.
    110       If <command>udevd</command> can't find a rule for the device it is
    111       creating, it will default permissions to <emphasis>660</emphasis> and
    112       ownership to <emphasis>root:root</emphasis>. </para>
    113 
    114     </sect3>
    115 
    116     <sect3>
    117       <title>Module Loading</title>
    118 
    119       <para>Device drivers compiled as modules may have aliases built into them.
    120       Aliases are visible in the output of the <command>modinfo</command>
    121       program and are usually related to the bus-specific identifiers of devices
    122       supported by a module. For example, the <emphasis>snd-fm801</emphasis>
    123       driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
    124       and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
    125       For most devices, the bus driver exports the alias of the driver that
    126       would handle the device via <systemitem
    127       class="filesystem">sysfs</systemitem>. E.g., the
    128       <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
    129       might contain the string
    130       <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
    131       The default rules provided by Udev will cause <command>udevd</command>
    132       to call out to <command>/sbin/modprobe</command> with the contents of the
    133       <envar>MODALIAS</envar> uevent environment variable (that should be the
    134       same as the contents of the <filename>modalias</filename> file in sysfs),
    135       thus loading all modules whose aliases match this string after wildcard
    136       expansion.</para>
    137 
    138       <para>In this example, this means that, in addition to
    139       <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
    140       <emphasis>forte</emphasis> driver will be loaded if it is
    141       available. See below for ways in which the loading of unwanted drivers can
    142       be prevented.</para>
    143 
    144       <para>The kernel itself is also able to load modules for network
    145       protocols, filesystems and NLS support on demand.</para>
    146 
    147     </sect3>
    148 
    149     <sect3>
    150       <title>Handling Hotpluggable/Dynamic Devices</title>
    151 
    152       <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
    153       player, the kernel recognizes that the device is now connected and
    154       generates a uevent. This uevent is then handled by
    155       <command>udevd</command> as described above.</para>
    156 
    157     </sect3>
     98      <quote>7:0</quote>. This string was used by <command>udevd</command>
     99      to create a device node with major number <emphasis>7</emphasis> and
     100      minor number <emphasis>0</emphasis>. Using the Udev method
     101      only those devices which are detected by the kernel would get device
     102      nodes created for them. Because these device nodes were created each time
     103      the system boots, they were stored on a
     104      <systemitem class="filesystem">tmpfs</systemitem> file system (a virtual
     105      file system that resides entirely in system memory). Device nodes do not
     106      require much space, so the memory that is used is negligible.</para>
     107
     108      <para>Linux kernel version 2.6.32 introduced a new virtual file system
     109      called <systemitem class="filesystem">devtmpfs</systemitem>, a
     110      replacement for <systemitem class="filesystem">devfs</systemitem>.
     111      With this approach, a
     112      <systemitem class="filesystem">devtmpfs</systemitem> file system is
     113      mounted on <filename class="directory">/dev/</filename> when the system
     114      is booted, and all needed device nodes are created on this virtual
     115      file system. As of version 176, Udev no longer creates device nodes
     116      itself, instead relying on
     117      <systemitem class="filesystem">devtmpfs</systemitem> to do so.</para>
     118
     119      <para>Udev also sets appropriate ownership and permissions
     120      for the device nodes, and creates extra symlinks as needed (such as
     121      <filename class="symlink">/dev/cdrom</filename>). The ownership and
     122      permissions of the nodes under the
     123      <filename class="directory">/dev</filename> directory are
     124      determined by rules specified in the files within the <filename
     125      class="directory">/etc/udev/rules.d/</filename> directory. These are
     126      numbered in a similar fashion to the CLFS-Bootscripts package. If
     127      <command>udevd</command> can't find a rule for the device it is creating,
     128      it will default permissions to <emphasis>660</emphasis> and ownership to
     129      <emphasis>root:root</emphasis>.</para>
     130
     131    </sect3>
     132
     133    <sect3>
     134      <title>Systemd and Eudev</title>
     135
     136        <para>In May 2012, Udev's source was merged with systemd, an alternate
     137        <command>init</command> implementation. Some time later, several Gentoo
     138        developers took the Udev code from systemd and created a fork called
     139        Eudev.</para>
     140
     141    </sect3>
     142
     143  </sect2>
     144
     145  <sect2>
     146    <title>Module Loading</title>
     147
     148    <para>Device drivers compiled as modules may have aliases built into them.
     149    Aliases are visible in the output of the <command>modinfo</command>
     150    program and are usually related to the bus-specific identifiers of devices
     151    supported by a module. For example, the <emphasis>snd-fm801</emphasis>
     152    driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
     153    and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
     154    For most devices, the bus driver exports the alias of the driver that
     155    would handle the device via <systemitem
     156    class="filesystem">sysfs</systemitem>. E.g., the
     157    <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
     158    might contain the string
     159    <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
     160    The default rules provided by Udev will cause <command>udevd</command>
     161    to call out to <command>/sbin/modprobe</command> with the contents of the
     162    <envar>MODALIAS</envar> uevent environment variable (that should be the
     163    same as the contents of the <filename>modalias</filename> file in sysfs),
     164    thus loading all modules whose aliases match this string after wildcard
     165    expansion.</para>
     166
     167    <para>In this example, this means that, in addition to
     168    <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
     169    <emphasis>forte</emphasis> driver will be loaded if it is
     170    available. See below for ways in which the loading of unwanted drivers can
     171    be prevented.</para>
     172
     173    <para>The kernel itself is also able to load modules for network
     174    protocols, filesystems and NLS support on demand.</para>
     175
     176  </sect2>
     177
     178  <sect2>
     179    <title>Handling Hotpluggable/Dynamic Devices</title>
     180
     181    <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
     182    player, the kernel recognizes that the device is now connected and
     183    generates a uevent. This uevent is then handled by
     184    <command>udevd</command> as described above.</para>
    158185
    159186  </sect2>
    … …  
    208235      sound cards available to OSS applications), configure
    209236      <command>modprobe</command> to load the wrapper after Udev loads the
    210       wrapped module. To do this, add an <quote>install</quote> line to a file
    211       in <filename>/etc/modprobe.d</filename>. For example:</para>
     237      wrapped module. To do this, add an <quote>install</quote> line in
     238      <filename>/etc/modprobe.conf</filename>. For example:</para>
    212239
    213240<screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \
    214241    /sbin/modprobe snd-pcm-oss ; true</literal></screen>
    215242
     243      <para>If the module in question is not a wrapper and is useful by itself,
     244      configure the <command>S05modules</command> bootscript to load this
     245      module on system boot. To do this, add the module name to the
     246      <filename>/etc/sysconfig/modules</filename> file on a separate line.
     247      This works for wrapper modules too, but is suboptimal in that case.</para>
     248
    216249    </sect3>
    217250
    … …  
    220253
    221254      <para>Either don't build the module, or blacklist it in
    222       <filename>/etc/modprobe.d</filename> file as done with the
     255      <filename>/etc/modprobe.conf</filename> file as done with the
    223256      <emphasis>forte</emphasis> module in the example below:</para>
    224257
    … …  
    256289
    257290    <sect3>
    258       <title>Udev does not create a device</title>
    259 
    260       <para>Further text assumes that the driver is built statically into the
    261       kernel or already loaded as a module, and that you have already checked
    262       that Udev doesn't create a misnamed device.</para>
    263 
    264       <para>Udev has no information needed to create a device node if a kernel
    265       driver does not export its data to <systemitem
    266       class="filesystem">sysfs</systemitem>.
    267       This is most common with third party drivers from outside the kernel
    268       tree. Create a static device node in
    269       <filename>/lib/udev/devices</filename> with the appropriate major/minor
    270       numbers (see the file <filename>devices.txt</filename> inside the kernel
    271       documentation or the documentation provided by the third party driver
    272       vendor). The static device node will be copied to
    273       <filename class="directory">/dev</filename> by the
    274       <command>S10udev</command> bootscript.</para>
    275 
    276     </sect3>
    277 
    278     <sect3>
    279291      <title>Device naming order changes randomly after rebooting</title>
    280292
Note: See TracChangeset for help on using the changeset viewer.