Changeset f6721f7 for BOOK


Ignore:
Timestamp:
May 21, 2014, 4:05:07 PM (11 years ago)
Author:
Chris Staub <chris@…>
Branches:
clfs-3.0.0-sysvinit, sysvinit
Children:
a720e96
Parents:
7b8e852
Message:

Rewrote Udev page

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r7b8e852 rf6721f7  
    2121  order.</para>
    2222
    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 Eudev 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>
    38 
    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>Eudev 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>Eudev Bootscript</title>
    96 
    97       <para>The <command>S10udev</command> initscript takes care of creating
    98       device nodes when Linux is booted. The script unsets the uevent handler
    99       from the default of <command>/sbin/hotplug</command>.  This is done
    100       because the kernel no longer needs to call out to an external binary.
    101       Instead <command>udevd</command> will listen on a netlink socket for
    102       uevents that the kernel raises. Next, the bootscript copies any static
    103       device nodes that exist in <filename
    104       class="directory">/lib/udev/devices</filename> to <filename
    105       class="directory">/dev</filename>. This is necessary because some devices,
    106       directories, and symlinks are needed before the dynamic device handling
    107       processes are available during the early stages of booting a system.
    108       Creating static device nodes in <filename
    109       class="directory">/lib/udev/devices</filename> also provides an easy
    110       workaround for devices that are not supported by the dynamic device
    111       handling infrastructure. The bootscript then starts the Eudev daemon,
    112       <command>udevd</command>, which will act on any uevents it receives.
    113       Finally, the bootscript forces the kernel to replay uevents for any
    114       devices that have already been registered and then waits for
    115       <command>udevd</command> to handle them.</para>
    116 
    117     </sect3>
    118 
    119     <sect3>
    120       <title>Device Node Creation</title>
    121 
    122       <para>To obtain the right major and minor number for a device, Eudev relies
    123       on the information provided by <systemitem
    124       class="filesystem">sysfs</systemitem> in <filename
    125       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,
    12697      <filename>/sys/class/tty/vcs/dev</filename> contains the string
    127       <quote>7:0</quote>. This string is used by <command>udevd</command>
    128       to create a device node with major number <emphasis>7</emphasis> and minor
    129       <emphasis>0</emphasis>. The names and permissions of the nodes created
    130       under the <filename class="directory">/dev</filename> directory are
     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
    131124      determined by rules specified in the files within the <filename
    132125      class="directory">/etc/udev/rules.d/</filename> directory. These are
    … …  
    134127      <command>udevd</command> can't find a rule for the device it is creating,
    135128      it will default permissions to <emphasis>660</emphasis> and ownership to
    136       <emphasis>root:root</emphasis>. Documentation on the syntax of the Eudev
    137       rules configuration files is available in
    138       <filename>/usr/share/doc/udev/writing_udev_rules/index.html</filename></para>
    139 
    140     </sect3>
    141 
    142     <sect3>
    143       <title>Module Loading</title>
    144 
    145       <para>Device drivers compiled as modules may have aliases built into them.
    146       Aliases are visible in the output of the <command>modinfo</command>
    147       program and are usually related to the bus-specific identifiers of devices
    148       supported by a module. For example, the <emphasis>snd-fm801</emphasis>
    149       driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801,
    150       and has an alias of <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
    151       For most devices, the bus driver exports the alias of the driver that
    152       would handle the device via <systemitem
    153       class="filesystem">sysfs</systemitem>. E.g., the
    154       <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> file
    155       might contain the string
    156       <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
    157       The default rules provided by Eudev will cause <command>udevd</command>
    158       to call out to <command>/sbin/modprobe</command> with the contents of the
    159       <envar>MODALIAS</envar> uevent environment variable (that should be the
    160       same as the contents of the <filename>modalias</filename> file in sysfs),
    161       thus loading all modules whose aliases match this string after wildcard
    162       expansion.</para>
    163 
    164       <para>In this example, this means that, in addition to
    165       <emphasis>snd-fm801</emphasis>, the obsolete (and unwanted)
    166       <emphasis>forte</emphasis> driver will be loaded if it is
    167       available. See below for ways in which the loading of unwanted drivers can
    168       be prevented.</para>
    169 
    170       <para>The kernel itself is also able to load modules for network
    171       protocols, filesystems and NLS support on demand.</para>
    172 
    173     </sect3>
    174 
    175     <sect3>
    176       <title>Handling Hotpluggable/Dynamic Devices</title>
    177 
    178       <para>When you plug in a device, such as a Universal Serial Bus (USB) MP3
    179       player, the kernel recognizes that the device is now connected and
    180       generates a uevent. This uevent is then handled by
    181       <command>udevd</command> as described above.</para>
    182 
    183     </sect3>
     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 Eudev 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>
    184185
    185186  </sect2>
    … …  
    288289
    289290    <sect3>
    290       <title>Eudev does not create a device</title>
    291 
    292       <para>Further text assumes that the driver is built statically into the
    293       kernel or already loaded as a module, and that you have already checked
    294       that Eudev doesn't create a misnamed device.</para>
    295 
    296       <para>Eudev has no information needed to create a device node if a kernel
    297       driver does not export its data to <systemitem
    298       class="filesystem">sysfs</systemitem>.
    299       This is most common with third party drivers from outside the kernel
    300       tree. Create a static device node in
    301       <filename>/lib/udev/devices</filename> with the appropriate major/minor
    302       numbers (see the file <filename>devices.txt</filename> inside the kernel
    303       documentation or the documentation provided by the third party driver
    304       vendor). The static device node will be copied to
    305       <filename class="directory">/dev</filename> by the
    306       <command>S10udev</command> bootscript.</para>
    307 
    308     </sect3>
    309 
    310     <sect3>
    311291      <title>Device naming order changes randomly after rebooting</title>
    312292
Note: See TracChangeset for help on using the changeset viewer.