Subversion Repositories svn LFS-FR

Rev

Rev 6583 | Blame | Compare with Previous | Last modification | View Log | RSS feed

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 <!ENTITY % general-entities SYSTEM "../../general.ent">
  %general-entities;
]>

<sect1 id="ch-config-udev">
  <?dbhtml filename="udev.html"?>

  <title>Gestion des périphériques et des modules sur un système CLFS</title>

  <indexterm zone="ch-config-udev">
    <primary sortas="a-Udev">Udev</primary>
    <secondary>usage</secondary>
  </indexterm>

  <para>Au <xref linkend="chapter-building-system"/>, nous avons installé Udev,
  composant de systemd. Avant d'entrer dans les détails sur son fonctionnement,
  un bref historique des méthodes de gestion précécentes des périphériques
  s'impose.</para>

  <sect2>
    <title>Historique</title>

    <sect3>
      <title>N&oelig;uds de périphériques statiques</title>

      <para>Les systèmes Linux en général utilisent traditionnellement une méthode
      de création statique des périphériques, par laquelle beaucoup de n&oelig;uds
      de périphériques sont créés dans <filename
     class="directory">/dev</filename> (parfois, litéralement des milliers de
      n&oelig;uds), que les périphériques matériels correspondants
      existnt effectivement ou pas. On fait cela en général avec un script
      <command>MAKEDEV</command>, qui contient un certain nombre d'appels au
      programme <command>mknod</command> avec les bons numéros majeurs et mineurs
      de périphériques pour chaque périphérique susceptible d'exister dans le
      monde.</para>

    </sect3>

    <sect3>
      <title>Devfs</title>

      <para>En février 2000, un nouveau système de fichiers appelé <systemitem
     class="filesystem">devfs</systemitem>, qui créait de manière dynamique
      des n&oelig;uds de périphériques quand des périphériques étaient découverts par le noyau, a été déposé dans
      le noyau 2.3.46 et rendu disponible dans la série 2.4 des noyaux stables.
      Bien que présent dans les sources du noyau lui-même, cette méthode de
      création dynamique de périphériques n'a jamais reçu un vrai support des
      développeurs du c&oelig;ur du noyau.</para>

      <para>Le principal problème de l'approche adoptée par <systemitem
     class="filesystem">devfs</systemitem> çtait la façon de gérer la
      détection, la création, et le nommage des périphériques, qui était sans
      doute la plus critique. Il est en général admis que si les noms de périphériques
      sont configurables, les règles de nommage des périphériques devraient
      dépendre de l'administrateur système, sans qu'il ne leur soit imposé par
      un développeur en particulier. Le système de fichiers <systemitem
     class="filesystem">devfs</systemitem> souffrait aussi de conflits (race
      conditions) inhérents à sa conception et insurmontables sans revue
      substantielle du noyau. Il a donc été noté obsolète dès la version 2.6 du
      noyau, puis complètement supprimé à partir de la version
      2.6.18.</para>

    </sect3>

    <sect3>
      <title>Sysfs</title>

      <para>Avec ;e développement de la branche 2.5 instable du noyau, dès la
      série 2.6 des noyaux stables, un nouveau système de fichiers virtuels,
      appelé <systemitem class="filesystem">sysfs</systemitem> est apparu. Le
      travail de <systemitem class="filesystem">sysfs</systemitem> est d'exporter
      une vision de la configuration matérielle du système vers les processus dans
      l'espace utilisateur. Les pilotes construits en dur dans le noyau enregistrent
      directement leurs objets avec
      <systemitem class="filesystem">sysfs</systemitem> dès qu'ils sont détectés
      par le noyau. Pour les pilotes compilés comme des modules, cet enregistrement
      se fera au chargement du module. Une fois que le système de fichiers <systemitem
     class="filesystem">sysfs</systemitem> est monté (dans <filename
     class="directory">/sys</filename>), les données enregistrées par
      les pilotes construits en dur avec <systemitem class="filesystem">sysfs</systemitem> sont
      disponibles pour les processus au niveau utilisateur. Avec une telle
      représentation visible au niveau utilisateur, la possibilité de voir un
      remplacement par l'espace utilisateur de <systemitem class="filesystem">devfs</systemitem>
      est devenue beaucoup plus réaliste.</para>

    </sect3>

    <sect3>
      <title>Implémentation d'Udev</title>

      <para>Peu après l'introduction de
      <systemitem class="filesystem">sysfs</systemitem>, un travail a commencé
      sur un programme appelé Udev pour en tirer parti. Le démon <command>udev</command>
      faisait des appels à <function>mknod()</function> pokr créer des n&oelig;uds
      de périphériques de fa¶on dynamique dans <filename class="directory">/dev</filename>,
      sur la base des informations de <systemitem class="filesystem">sysfs</systemitem>, dans
      <filename class="directory">/sys</filename>. Par exemple,
      <filename>/sys/class/tty/vcs/dev</filename> contient la chaîne´
      <quote>7:0</quote>. Cette chaîne était utilisée par <command>udev</command>
      pour créer un n&oelig;ud de périphérique au numéro majeur <emphasis>7</emphasis>
      et au numéro mineur <emphasis>0</emphasis>.</para>

      <para>Le noyau Linux version 2.6.32 a introduit un nouveau système de
      fichiers virtuel appelé <systemitem class="filesystem">devtmpfs</systemitem>,
      remplacement amélioré de <systemitem class="filesystem">devfs</systemitem>.
      Ceci permet aux n&oelig;uds de périphériques de se créer de nouveau
      dynamiquement par le noyau, sans les nombreux problèmes de
      <systemitem class="filesystem">devfs</systemitem>. À partir de la version 176,
      Udev ne crée plus de n&oelig;uds de périphériques en soi, s'appuyant
      plutôt sur <systemitem class="filesystem">devtmpfs</systemitem> pour
      le faire</para>

    </sect3>

    <sect3>
      <title>Systemd et Eudev</title>

        <para>En 2010, le développement de systemd a commencé, alternative à
        l'implémentation <command>init</command>. À partir d'Udev 183, l'arborescence
        des sources d'Udev a été fusionnée avec systemd. Des développeurs Gentoo
        en désaccord avec cette fusion ont annoncé un projet appelé
        Eudev en décembre 2012, créé par l'extraction du code
        d'Udev de systemd. Un des buts d'Eudev est de permettre une
        installation et une utilisation plus faciles de <command>udevd</command>
        sans avoir besoin du reste de systemd.</para>
    </sect3>

  </sect2>

  <sect2>
    <title>Création des n&oelig;uds de périphériques</title>

    <para>Par défaut, les n&oelig;uds de périphérique créés par le noyau dans
    <systemitem class="filesystem">devtmpfs</systemitem> appartiennent à
    <emphasis>root:root</emphasis> avec les droits <emphasis>600</emphasis>.
    <command>udevd</command> peut modifier l'appartenance et les droits des
    n&oelig;uds dans le répertoire <filename class="directory">/dev</filename>,
    et créer des liens symboliques supplémentaires basés sur les règles spécifiées
    dans les fichiers contenus dans les répertoires
    <filename class="directory">/etc/udev/rules.d</filename>,
    <filename class="directory">/lib/udev/rules.d</filename>,
    et <filename class="directory">/run/udev/rules.d</filename>.
    Les noms de ces fichiers commencent par un nombre, pour indiquer l'ordre
    d'exécution, puis ils ont une extension <filename>.rules</filename>
    (<command>udevd</command> ignorera les fichiers ayant d'autres
    extension). Tous les fichiers de règles de ces répertoires sont réunis dans
    une liste unique, triée par noms de fichiers, et lancés dans cet ordre. En
    cas de conflit, si un fichier de règles a le même nom dans deux ou plusieurs
    répertoires, les règles de <filename class="directory">/etc</filename> sont
    les plus prioritaires, suivies des fichiers de règles de
    <filename class="directory">/run</filename>, et enfin
    <filename class="directory">/lib</filename>. Tout périphérique pour lequel
    on ne trouve pas de règle sera tout simplement ignoreé par <command>udevd</command>
    et utilisé avec ses paramètres par défaut définis par le noyau, comme décrit
    ci-dessus. Pour plus de détails sur l'écriture de règles Udev, voir
    <filename><ulink url="/usr/share/doc/systemd-&systemd-version;/udev.html"/></filename>.</para>

  </sect2>

  <sect2>
    <title>Chargement des modules</title>

    <para>Les pilotes de périphériques compilés comme des modules peuvent avoir
    des aliases construits en dur. Les
    alias sont consultables dans la sortie du programme <command>modinfo</command>
    et ils sont liés généralement aux identifiants uniques de bus des périphériques
    supportés par un module. Par exemple, le pilote <emphasis>snd-fm801</emphasis>
    supporte les périphériques PCI dont l'ID constructeur est 0x1319 et l'ID du
    périphérique est 0x0801, son alias est <quote>pci:v00001319d00000801sv*sd*bc04sc01i*</quote>.
    Pour la plupart des périphériques, le pilote du bus exporte l'alias du pilote
    qui gérerait le périphérique à travers <systemitem
   class="filesystem">sysfs</systemitem>. Ainsi, le fichier
    <filename>/sys/bus/pci/devices/0000:00:0d.0/modalias</filename> pourrait
    contenir la chaîne
    <quote>pci:v00001319d00000801sv00001319sd00001319bc04sc01i00</quote>.
    Les règles par défaut fournies par Udev amèneront <command>udevd</command>
    à appeler <command>/sbin/modprobe</command> avec le contenu de la variable
    d'environnement d'uevent <envar>MODALIAS</envar> (cela devrait être le même
    contenu que dans le fichier <filename>modalias</filename> dans sysfs),
    chargeant ainsi tous les modules dont les alias correspondent à cette chaîne
    après l'expansion du joker.</para>

    <para>Dans cet exemple, cela signifie que, outre
    <emphasis>snd-fm801</emphasis>, le pilote
    <emphasis>forte</emphasis> obsolète (et non désiré) sera chargé s'il est
    disponible. Voir ci-dessous les manières d'empêcher le chargement de
    pilotes non souhaités.</para>

    <para>Le noyau lui-même est également capable de de charger des modules pour
    des protocoles réseaux, des systèmes de fichiers et le support NLS à la
    demande.</para>

  </sect2>

  <sect2>
    <title>Problème de chargement des modules et création de périphériques</title>

    <para>Quelques problèmes sont possibles lors d la création automatique
    de n&oelig;uds de périphériques.</para>

    <sect3>
      <title>Un module du noyau n'est pas chargé automatiquement</title>

      <para>Udev ne chargera un module que s'il a un alias spécifique au bus
      et si le pilote du bus exporte les alias nécessaires vers <systemitem
     class="filesystem">sysfs</systemitem>. Sinon, vous devriez organiser le
      chargement des modules autrement. Avec Linux-&linux-version2;, Udev
      est connu pour charger les pilotes bien écrits pour les périphériques
      INPUT (d'entrée), IDE, PCI, USB, SCSI,
      SERIO et FireWire.</para>

      <para>Pour savoir si le pilote de périphérique que vous souhaitez dispose
      du support pour Udev, lancez <command>modinfo</command> avec le nom du
      module en argument. Maintenant, essaye[ de localiser le répertoire sous
      <filename class="directory">/sys/bus</filename> et vérifiez si s'y trouve un
      fichier <filename>modalias</filename>.</para>

      <para>Si le fichier <filename>modalias</filename> existe dans <systemitem
     class="filesystem">sysfs</systemitem>, le silote supporte le périphérique et
      peut lui parler directement, mais il n'a pas d'alias, ce qui est un bogue
      du pilote. Chargez le pilote sans l'aide d'Udev en espérant que le problème
      sera réglé ultérieurement.</para>

      <para>S'il n'y a pas de fichier <filename>modalias</filename> dans le
      répertoire adéquat sous <filename class="directory">/sys/bus</filename>,
      cela veut dire que les développeurs du noyau n'ont pas encore ajouté de support
      modalias à ce type de bus. Avec Linux-&linux-version2;, tel est le cas
      des bus ISA. Attendez que cela soit réglé dans les prochaines
      versions du noyau.</para>

      <para>Udev n'est pas censé charger les pilotes <quote>wrapper</quote>
      tels que <emphasis>snd-pcm-oss</emphasis> et les pilotes non matériels
      comme <emphasis>loop</emphasis>.</para>

    </sect3>

    <sect3>
      <title>Un module du noyau n'est pas chargé automatiquement et Udev n'est
      pas censé le charger</title>

      <para>Si le module <quote>wrapper</quote> (enveloppe) ne prend en charge
      que la fonctionnalité fournie par d'autres modules (exemple, <emphasis>snd-pcm-oss</emphasis>
      gère la fonctionnalité de´<emphasis>snd-pcm</emphasis> en rendant les cartes
      son disponibles pour les applications OSS), configurez
      <command>modprobe</command> pour charger l'enveloppe après qu'Udev charge
      le module à l'intérieur. Mour ce faire, ajoutez une ligne <quote>install</quote>
      à un fichier de <filename>/etc/modprobe.d</filename>. Par exemple&nbsp;:</para>

<screen role="nodump"><literal>install snd-pcm /sbin/modprobe -i snd-pcm ; \
    /sbin/modprobe snd-pcm-oss ; true</literal></screen>

      <para>Si le module en question n'est pas une enveloppe et utile en soi,
      configurez le script de démarrage <command>S05modules</command> pour
      charger ce module au démarrage du système. Pour ce faire, ajoutez le nom
      du module au fichier
      <filename>/etc/sysconfig/modules</filename> dans une ligne à part.
      Ce;a fonctionne aussi avec les modules enveloppe, mais c'est sous-optimal
      dans ce cas.</para>

    </sect3>

    <sect3>
      <title>Udev charge un module non souhaité</title>

      <para>Soit, ne construisez pas le module, soit blacklistez-le dans un fichier
      <filename>/etc/modprobe.d</filename> comme ceci pour le module
      <emphasis>forte</emphasis> dans l'exemple ci-dessous&nbsp;:</para>

<screen role="nodump"><literal>blacklist forte</literal></screen>

      <para>Vous pouvez toujours charger des modules blacklistés à la main avec
      commande <command>modprobe</command> explicite.</para>

    </sect3>

    <sect3>
      <title>Udev crée un mauvais lien symbolique</title>

      <para>Cela arrive en général si une règle correspond inopportunément à
      un périphérique. Par exemple, une règle mal écrite peut correspondre à la
      fois à un disque SCSI (comme décrit) et au périphérique SCSI générique
      associé (c'est incorrect) via le fabricant. Idensifiez la règle erronée
      pour la rendre plus spécifique, à l'aide de
      <command>udevadm info</command>.</para>

    </sect3>

    <sect3>
      <title>Une règle Udev ne fonctionne pas de façon fiable</title>

      <para>Cela peut être une autre manifestation du problème précédent. Sinon
      et si votre règle utilise attributs <systemitem class="filesystem">sysfs</systemitem>,
      c'est peut-être un problème de timing du noyau qui sera corrigé dans les
      prochains noyaux. En attendant, vous pouvez le contourner en créant une règle
      qui attend l'attribut <systemitem class="filesystem">sysfs</systemitem> et
      en l'envoyant dans le fichier <filename>/etc/udev/rules.d/10-wait_for_sysfs.rules</filename>.
      Merci de signaler à la ;iste de développement de CLFS si vous faites ainsi
      et si cela marche.</para>

    </sect3>

    <sect3>
      <title>L'ordre de nommage des périphériques change de fçon aléatoire après
      un redémarrage</title>

      <para>C'est dû au fait qu'Udev, par nature, gère les uevents et charge les
      modules en parallèle, dans un ordre ainsi imprévisible. Cela ne sera jamais
      <quote>corrigé</quote>. Vous ne devriez pas vous fier à la stabilité des
      noms de périphérique du noyau  Créez plutôt vos propres règles pour faire
      des liens symboliques avec des noms stables sur la base d'attributs
      du périphérique, tels qu'un numéro de série ou la sortie des outils *_id
      installés par Udev.
      Voir <xref linkend="ch-config-symlinks"/> et
      <xref linkend="chapter-network"/> pour des exemples.</para>

    </sect3>

  </sect2>

  <sect2>
    <title>Lecture utile</title>

    <para>De la documentation supplémentaire utile est disponible sur les
    sites suivants&nbsp;:</para>

    <itemizedlist>

      <listitem>
        <para remap="verbatim">A Userspace Implementation of <systemitem class="filesystem">devfs</systemitem>
        <ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"/></para>
      </listitem>

      <listitem>
        <para remap="verbatim">The <systemitem class="filesystem">sysfs</systemitem> Filesystem
        <ulink url="http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf"/></para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>