Retrouvez cet article dans : Linux Pratique 38

Linux supporte un très grand nombre de périphériques sans aucun problème. Il a cependant longtemps manqué le fait que le périphérique soit fonctionnel dès son branchement. À quoi sert un environnement graphique si, pour lire une clé USB, il est nécessaire de recourir à de nombreuses manipulations en ligne de commande ? L'utilisation de plusieurs couches logicielles, avec entre autres HAL, permet de résoudre ce problème.

La méthode historique

Avant l'arrivée de HAL (voir plus loin) et des versions de KDE et Gnome gérant l'insertion de périphériques, il n'était pas simple d'aller lire une clé USB. Ou plutôt, c'était très fastidieux et répétitif...

Identifier le fichier périphérique

Il s'agit de repérer dans le répertoire /dev quelle entrée correspond à votre clé USB. On peut par exemple utiliser la commande lsscsi qui donne une sortie du type :

[3:0:0:0]  disk  Generic  USB Flash Disk   2.00  /dev/sda

Vous êtes probablement étonné de l'utilisation de la commande lsscsi ou même de l'utilisation du nom sda pour un périphérique USB, ces noms étant destinés a priori aux périphériques SCSI. C'est cependant tout à fait normal : le noyau Linux utilise une partie des drivers SCSI pour supporter les périphériques de stockage de masse. Ainsi la clé USB correspond ici au fichier /dev/sda.

Monter le périphérique

Ce fichier identifié, supposons que ce soit /dev/sda, il s'agit maintenant de monter la clé USB sur un répertoire. Cette opération consiste à définir un répertoire dans lequel apparaîtra le contenu de la clé : c'est ce qu'on appelle " le point de montage ". C'est valable pour tous les périphériques de stockage de données : par exemple, les distributions Linux montent généralement automatiquement les CD-ROM sur le répertoire /mnt/cdrom ou encore /media/cdrom. En vous rendant dans ce répertoire, vous verrez alors le contenu du CD-ROM. Deux solutions se présentent pour monter une clé USB :

• si vous pouvez vous loguer en tant qu'utilisateur root, vous pouvez effectuer cette opération directement, sans qu'une entrée ne soit définie au préalable dans le fichier /etc/fstab. Tout d'abord, il faut créer le répertoire dans lequel le contenu de la clé apparaîtra :

# mkdir /mnt/cleusb

Ensuite, il faut associer ce point de montage au fichier de périphérique de /dev à l'aide de la commande mount :

# mount -t vfat -o umask=000 /dev/sda /mnt/cleusb

L'option -t vfat permet de préciser que le système de fichiers de la clé est le format FAT et l'option -o umask=000 que les fichiers de la clé seront lisibles, modifiables et exécutables par tout le monde. Une fois cela fait, vous pouvez repasser en utilisateur normal et vous verrez le contenu de votre clé USB en vous rendant dans le répertoire /mnt/cleusb, que ce soit en console ou dans votre navigateur de fichiers. l'autre méthode, plus propre – on ne le répétera jamais assez, mais il faut toujours minimiser le temps passé en tant qu'utilisateur root pour minimiser les risques d'erreurs irréparables –, nécessite l'ajout d'une ligne dans le fichier /etc/fstab. Pour cela, vous devez vous loguer en tant qu'utilisateur root. Tout d'abord, créez le répertoire /mnt/cleusb. Utilisez maintenant votre éditeur de texte préféré pour éditer le fichier /etc/fstab :

$ emacs /etc/fstab

Vous y ajoutez alors la ligne suivante :

/dev/sda  /mnt/cleusb  vfat  defaults,rw,user 0 0

Le premier élément correspond au périphérique, le deuxième au point de montage et le troisième au type de système de fichiers. La quatrième colonne contient les options de montage, séparées par une virgule : rw signifie que la clé sera montée en lecture et en écriture et user signifie que n'importe quel utilisateur pourra monter la clé. Cela fait, une fois pour toutes, vous pouvez en tant qu'utilisateur normal lancer la commande mount /mnt/cleusb et le périphérique /dev/sda sera alors monté. De même que dans le cas précédent, il suffit alors de se rendre dans le répertoire /mnt/cleusb pour lire le contenu du périphérique.

Conclusion

Cela marche bien, c'est facile à faire si on en a l'habitude, mais c'est très ennuyeux, surtout pour une clé USB que l'on branche et débranche sans cesse. Une méthode automatisant tout cela serait la bienvenue ! Elle existe et propose beaucoup d'autres avantages :

• elle permet d'automatiser le montage des disques externes et clés USB ;
• elle permet de les faire apparaître avec des noms évocateurs : votre clé USB apparaît ainsi sous le nom de " clé USB " ou encore " usbdisk " et non plus /dev/sda, et ce, de façon automatique !
• enfin, l'avantage précédent permet aussi d'identifier sûrement votre périphérique : autant est-on sûr que " clé USB " correspond bien à votre clé USB, autant personne ne peut affirmer que /dev/sda est bien votre clé USB et non pas un autre disque dur externe (imaginez que vous formatiez le mauvais...).

La solution : un ensemble de couches logicielles

Les nouvelles versions de KDE et de Gnome gèrent maintenant l'insertion de clés USB, de disques durs ou d'appareils photo " à chaud " et de manière transparente pour l'utilisateur. Cette transparence est possible grâce à un ensemble de librairies et de technologies qui vont permettre aux environnements graphiques d'identifier ces périphériques et de faire par exemple apparaître l'icône correspondante sur le bureau.

Ces librairies s'organisent en différentes couches (Fig. 1). Juste au-dessus du noyau, on trouve udev. Communiquant avec ce dernier se trouve HAL (Hardware Abstraction Layer) qui, d'autre part, utilise D-Bus pour communiquer avec les applications.

Udev

Présentation

Le répertoire /dev sur un ordinateur utilisant Linux est constitué de fichiers représentant les périphériques. Les applications peuvent accéder aux périphériques via ces fichiers. Par exemple, le fichier /dev/hda correspond au disque dur principal de votre ordinateur. La structure du répertoire /dev est gérée par udev. Udev a remplacé l'ancien devfs. En particulier, udev veille à ce qu'un même périphérique garde toujours la même entrée. Imaginez que vous ayez deux imprimantes branchées sur deux ports USB. L'ancien système, devfs, leur aurait attribué dans l'ordre les fichiers /dev/usb/lp0 et /dev/usb/lp1. Imaginez alors que vous les déplaciez sur un hub pour une raison quelconque. Rien ne garantissait qu'elle ne soit pas échangée. Et donc qu'en croyant imprimer une photo sur l'imprimante photo, vous l'imprimiez sur l'infâme vieille imprimante qui ne sert qu'aux factures... udev vise entre autres à résoudre ce problème.

Écriture d'une règle pour udev

Pour cela, udev supporte l'écriture de règles. Ces règles permettent d'assigner un fichier dans le répertoire /dev en fonction du matériel détecté. Considérons un exemple simple et utile. Nombreux sont les possesseurs d'iPod. Ce baladeur apparaît par défaut sous le joli nom de /dev/sda2 ou /dev/sd?2 (où ? peut être n'importe quelle lettre). Ne serait-il pas plus agréable que l'iPod apparaisse sous le nom de /dev/ipod ? Rien de plus simple. Les règles sont dans des fichiers situés dans le répertoire /etc/udev/rules.d. Ces fichiers sont lus dans l'ordre lexicographique (c'est la raison pour laquelle dans certaines distributions leur nom commence par un nombre). Cet ordre peut être important dans certains cas. Nous créons donc le fichier 00-ipod.rules dans lequel nous plaçons la ligne suivante :

BUS="scsi", SYSFS{model}="iPod*", SYMLINK="ipod"

Les deux premiers éléments correspondent à un filtre : si le BUS est SCSI (un disque externe est reconnu comme un périphérique SCSI) et que le modèle est un iPod, alors, créer un lien symbolique /dev/ipod vers le fichier correspondant de /dev (en général /dev/sda2). Bien sûr, c'est un exemple très simple et les possibilités sont grandes 1.

1 Pour aller plus loin : " Comment écrire des règles pour udev ? " http://www.reactivated.net/writing_udev_rules.html 2 Le document fondateur de HAL : Making Hardware Just Work, http://www.ometer.com/hardware.html

Hardware Abstraction Layer (HAL)

Créé en 2003 2, HAL est un démon qui communique avec udev et il reçoit des notifications lorsque des périphériques sont ajoutés ou retirés.

Communication avec udev

Cette communication se fait toujours au moyen des règles que nous avons vues précédemment. De la même manière que SYMLINK crée un lien symbolique vers un fichier, il existe une " commande " RUN qui permet d'appeler un programme donné. Le fichier /etc/udev/rules.d/90-hal.rules utilise ce principe, à peu de choses près, puisqu'il se contente d'utiliser une socket (un système permettant à deux applications de communiquer) :

# pass all events to the HAL daemon
RUN+="socket:/org/freedesktop/hal/udev_event"

Informations sur les périphériques

Le démon maintient en mémoire une liste des périphériques actifs et leurs propriétés. Ces propriétés sont stockées sous forme de paires clé/valeur définies par les spécifications de HAL 3. Mais pour associer à chaque clé sa valeur, HAL utilise différentes sources : 3 HAL en détail : les spécifications, http://webcvs.freedesktop.org/hal/hal/doc/spec/hal-spec.html

• là où le noyau se limite à repérer les différentes partitions, HAL va regarder quel est leur format (FAT, ext2, etc.) au prix d'un léger surcoût en accès disque.
• HAL possède un certain nombre d'informations préenregistrées (par exemple, quels formats audio sont supportés par tel baladeur, etc.).
• certains périphériques sont surveillés par HAL qui récupère ainsi des informations dynamiques comme la vitesse d'une connexion réseau.

Ainsi, HAL rassemble à partir de différentes sources des informations sur le périphérique. A l'aide des informations transmises par udev comme VendorId ou ProductId, HAL est capable d'identifier sûrement le périphérique et de connaître son type. C'est ce qui fait sa grande force par rapport au noyau qui est incapable de dire si le périphérique est une clé USB ou un disque dur externe par exemple. Bien sûr, cela nécessite une sorte de base de donnée. On la trouve stockée au format XML dans le répertoire /usr/share/hal/fdi. En voici un extrait :

<match key="storage.bus" string="usb">
   <match key="storage.drive_type" string="disk">
       <match key="storage.vendor" string="IOMEGA">
	<match key="storage.model" contains_ncase="ZIP">
	<merge key="storage.drive_type"
 	type="string">zip</merge>
	<merge key="storage.requires_eject"
	type="bool">true</merge>
	</match>
       </match>
   </match>
</match>

On remarque deux principales instructions : match et merge/append. match correspond à des conditions que doit vérifier le périphérique pour que les instructions merge (fusionner) ou append (ajouter) soient appliquées. Ici, si la marque est IOMEGA et que le modèle contient ZIP, HAL peut être sûr que le périphérique est une disquette zip et sait que ce type de disquette peut être éjecté logiciellement (comme un lecteur CD, contrairement à une clé USB). En rassemblant toutes ces sources, HAL possède en mémoire des informations actualisées sur les périphériques. Un moyen simple de voir ces informations consiste à utiliser la commande lshal fournie avec HAL. Vous constaterez ainsi que HAL en sait beaucoup, et sur beaucoup de périphériques. Le logiciel hal-device-manager permet d'afficher ces informations sous forme d'arbres dans une fenêtre. Il faut bien comprendre que HAL est seulement là pour permettre d'identifier le matériel et de déterminer ses capacités. Mais il ne s'interpose pas dans les communications entre les logiciels et le matériel. HAL propose des informations concernant les périphériques et, en particulier, il propose le chemin pour y accéder. Mais il ne gère pas l'accès. Les communications ne sont donc pas ralenties par cette couche supplémentaire.

Comment l'environnement graphique est-il notifié ?

Lorsque HAL a identifié le périphérique, il va utiliser une autre technologie : D-Bus. D-Bus est un système qui permet aux applications de communiquer entre elles, toujours à l'aide d'un démon qui redistribue les messages. HAL envoie alors un message sur D-Bus prévenant qu'un nouveau périphérique est disponible ; l'environnement graphique (KDE ou Gnome), connecté à D-Bus (c'est-à-dire qu'il lit les messages qui y arrivent) reçoit le message et va alors prendre les décisions en conséquence.

L'environnement KDE

La liste des périphériques de stockages est accessible dans Konqueror. Lorsqu'un nouveau périphérique est ajouté, KDE propose différents choix à l'utilisateur en fonction de celui-ci : si c'est une clé USB, par exemple, l'ouvrir avec Konqueror ou y rechercher des photos avec Digikam ; si c'est un CD audio, le lire ou extraire les fichiers à l'aide de KAudioCreator. Le choix des actions à effectuer par défaut lors de l'insertion d'un média se fait dans le panneau de contrôle de KDE.

KDE propose plusieurs choix lors de l'insertion d'une clé USB (Fig. 2). En général, à moins que vous choisissiez de ne rien faire, KDE va se charger de monter le périphérique. KDE fait appel au programme pmount qui va se charger de monter le périphérique. Pourquoi ne pas utiliser mount ? Tout simplement parce que mount n'a pas les permissions nécessaires pour monter les périphériques qui n'ont pas une entrée dans le fichier /etc/fstab. Pmount permet de contourner ce problème. Les périphériques apparaissent dans le Media Manager de KDE (Fig. 3). Avec un clic droit sur l'un des périphériques et en utilisant l'option Propriétés, en particulier sous l'onglet Montage, vous accédez à de nombreuses options qui correspondent à celles de la commande mount. Généralement, elles correspondent à des besoins très spécifiques et vous n'aurez pas à les modifier.

 

Enfin, l'option Éjecter du menu contextuel est à utiliser avant de retirer le périphérique. Cela revient à utiliser la commande umount. Ainsi, en utilisant cette option, vous serez sûr de ne pas retirer le périphérique alors que des écritures sont encore en cours. Il peut arriver qu'une copie vers un tel périphérique apparaisse comme terminée, mais que l'utilisation d'une mémoire tampon fasse que toutes les données ne soient pas encore écrites...

 

L'environnement Gnome

Le logiciel gnome-volume-properties permet de configurer le comportement de Gnome lors de l'insertion d'un média. Gnome intègre un logiciel nommé Gnome Volume Manager (Fig. 4) qui permet de choisir les actions à effectuer lors de l'insertion d'un nouveau media et les exécute au moment de l'insertion. La figure 4 représente l'onglet des volumes de stockage ; en général, ce sont ces derniers qui nous intéressent. Par défaut, on constate que les disques sont automatiquement montés et que le navigateur sera automatiquement ouvert sur le nouveau média.

 

De même, le navigateur de fichiers de Gnome en tire parti et affiche des informations bien plus détaillées. Ainsi, vous ne voyez plus /mnt/hdd mais External CD-RW/DVD+R Drive. C'est bien plus agréable et cela facilite l'identification des lecteurs. Enfin, lors de l'éjection d'un périphérique, Gnome présente une barre de progression donnant l'avancement de l'écriture du cache sur le disque, ce qui est bien sympathique (n'oublions pas que les actions du type Retirer en toute sécurité, Éjecter ou Démonter le volume, visent à écrire totalement le cache sur le disque pour éviter les corruptions de fichiers sur le périphérique).

 

 

Et comment installer tout cela ?

Si votre distribution est récente, une fois installée, KDE et Gnome gèrent parfaitement l'insertion de tels périphériques. Si ce n'était pas le cas, les paquets suivants, et leurs dépendances, sont probablement à installer : hal, dbus et pmount (et éventuellement ivman pour KDE 3.5). Veillez à ce que le démon hald soit lancé. Si votre noyau est trop vieux et qu'udev n'est pas présent, HAL ne pourra pas fonctionner et vous aurez alors à installer un noyau récent (> 2.6).

Conclusion

Le domaine du Plug&Play sous Linux est en évolution assez rapide. Nous avons abordé dans cet article les technologies dans l'état où elles sont actuellement, car il est impossible de traiter tous les cas précédents. En particulier, sachez que hotplug et coldplug, auxquels il est souvent fait référence, sont maintenant dépassés et pris en charge par udev. Sachez également que ce domaine évolue très vite et qu'au moment où vous lirez ces lignes, des nouveautés très intéressantes auront peut-être été introduites. Ce n'est pas dans un article aussi court que nous pouvons entrer dans tous les détails : en particulier, il est impossible de parler de tous les problèmes qui pourraient survenir. En revanche, comprendre l'enchaînement des librairies et des technologies permet de chercher là où il faut en cas de besoin. Le Plug&Play parfait est maintenant l'un des objectifs des distributions Linux. Des projets comme Solid 4 du futur KDE 4 promettent de s'en rapprocher...

 

4 Solid est un projet KDE qui vise à proposer un meilleur support du hardware et de la connectivité réseau (http://solid.kde.org).