Guide Devfs (Device File System, système de fichiers des périphériques)
Les implémentations traditionnelles de linux fournissent aux utilisateurs un répertoire abstrait pour les périphériques, nommé /dev. L'utilisateur y trouvera des périphériques logiques (nous utiliserons le terme « fichiers de périphériques » dans la suite), des fichiers spéciaux qui représentent les périphériques au sein du système de fichiers. Par exemple, /dev/hda représente le premier périphérique IDE du système. Ces fichiers de périphériques permettent aux utilisateurs d'écrire des programmes qui interagissent avec le matériel comme si le périphérique était un fichier comme les autres. Ils n'ont donc pas besoin de faire appel à la moindre API spécifique. Les fichiers de périphériques sont partagés en deux groupes, dits périphériques en mode caractère et périphériques en mode bloc. Le premier groupe contient le matériel pour lequel les entrées/sorties se font sans utilisation d'un cache. Dans le cas contraire, on dit que le périphérique a un mode d'accès de type bloc (donc utilisant un cache). Si vous jetez un coup d'œil à un fichier de périphérique, vous trouverez quelque chose de ce genre :
Dans cet exemple nous voyons que /dev/hda est un périphérique de bloc (« b »). Cependant, ce qui est encore plus important, c'est qu'il a deux numéros spéciaux qui lui sont assignés : 3, 0. Cette paire est appelée la paire majeur-mineur. Elle est utilisée par le noyau pour faire la correspondance entre le fichier périphérique et le matériel physique. Le majeur correspond à un certain périphérique, le mineur à un sous-périphérique. Cela semble confus ? Ça ne l'est pas si l'on considère l'exemple qui suit. Prenons le cas de /dev/hda4 et /dev/tty5. Le premier périphérique correspond à la quatrième partition du premier périphérique IDE. Sa paire majeur-mineur est 3, 4. En d'autres termes, le mineur correspond à la partition et le majeur correspond au disque dur IDE. Le second exemple a 4, 5 comme paire majeur-mineur. Cette fois, le majeur représente le pilote du terminal et le mineur le numéro du terminal (le cinquième dans notre exemple). Si vous faites une analyse rapide du répertoire /dev, vous ne trouverez pas seulement vos périphériques, mais tous les périphériques possibles et imaginables. En d'autres termes, vous avez des fichiers périphériques pour du matériel physique que vous ne possédez pas forcément. Gérer un tel groupe de périphériques est pour le moins gênant. Imaginez devoir changer les permissions de tous les fichiers de périphériques qui correspondent à un périphérique de votre système et laisser le reste des fichiers tels qu'ils sont. Lorsque vous ajoutez un nouveau périphérique à votre système et que ce périphérique n'avait pas auparavant de fichier spécial, vous devez le créer. Les utilisateurs expérimentés savent que cette tâche peut être accomplie avec la commande ./MAKEDEV depuis la racine de l'arborescence /dev, mais savez-vous facilement quel périphérique vous devez créer ? Quand vos programmes interagissent avec un périphérique en utilisant un fichier de périphérique, la partition racine ne peut pas être montée en mode lecture seule alors qu'il n'est pas nécessaire de la monter en mode lecture/écriture. Vous ne pouvez pas non plus avoir /dev sur une partition séparée puisque mount a besoin de /dev pour monter les partitions. Comme vous pouvez l'imaginer, les développeurs du noyau ont trouvé bon nombre de solutions pour résoudre les problèmes mentionnés précédemment. Cependant, certains d'entre eux ont une autre vision de la chose, comme décrit dans http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why. Nous ne parlerons pas ici de ces implémentations, mais nous nous concentrerons sur celle qui est utilisée dans les sources officielles du noyau : devfs. devfs aborde tous les problèmes énoncés. Il fournit simplement à l'utilisateur les périphériques existants, ajoute les « i-nodes » lorsqu'un nouveau périphérique est découvert, et rend possible le montage de la partition racine en mode lecture seulement. Il aborde aussi des problèmes dont nous n'avons pas discuté précédemment puisqu'ils sont moins intéressants pour l'utilisateur. Par exemple, avec devfs, vous n'avez pas à vous occuper des paires majeur/mineur. Elles sont aussi supportées (pour des raisons de compatibilité avec le schéma existant), mais pas nécessaires. Cela donne la possibilité au noyau linux de supporter plus de périphériques puisqu'il n'y a plus de limite (les nombres ont toujours une limite :). Pourtant, devfs n'est pas non plus sans problème ; pour les utilisateurs, les difficultés ne sont pas apparentes mais, pour les développeurs du noyau, ces problèmes étaient si importants que devfs est aujourd'hui considéré obsolète. Il est désormais remplacé par udev qui est non seulement supporté par Gentoo, mais aussi utilisé par défaut sur la plupart des architectures depuis Gentoo/2005.0. Pour savoir pourquoi devfs a été délaissé au profit de udev, vous pouvez consulter la FAQ udev et le document udev versus devfs (tous deux en anglais). 2. Parcourir l'arborescence dev Une des premières choses que vous devez savoir est que devfs utilise des répertoires pour regrouper les périphériques. Cela augmente la lisibilité, étant donné que maintenant tous les périphériques du même type sont dans un répertoire commun. Par exemple, tout périphérique IDE est dans le répertoire de périphériques /dev/ide/, et les périphériques SCSI sont dans /dev/scsi/. Les disques SCSI et IDE sont vus de la même façon, c'est-à-dire qu'ils ont tous deux la même structure de sous-répertoires. Les disques SCSI et IDE sont contrôlés par un adaptateur (sur la carte mère ou sur une carte séparée), appelé l'hôte (« host »). Chaque adaptateur peut avoir différents canaux. Un canal est appelé un bus. Sur chaque canal, vous pouvez avoir divers ID. De tels ID identifient un disque. Cet identifiant est appelé la cible (« target »). Certains périphériques SCSI peuvent avoir divers LUN (Numéro d'Unité Logique), par exemple les périphériques qui manipulent plusieurs médias simultanément (DAT). Vous aurez généralement un seul lun, lun0/. Donc, en considérant le /dev/hda4 utilisé précedemment, nous avons maintenant /dev/ide/host0/bus0/target0/lun0/part4. C'est bien plus simple ainsi... non, ne polémiquez pas avec moi... c'est plus facile... rha, peut importe ! :)
Pour vous donner une idée de l'arborescence, voilà une liste des répertoires que j'ai sur mon ordinateur portable :
Compatibilité avec le schéma existant dans devfsd En utilisant ce nouveau schéma qui semble plus sympa, on se heurte aux divers outils et programmes qui utilisent l'ancien schéma. Pour être sûr qu'aucun système ne soit pénalisé, devfsd a été créé. Ce démon crée des liens symboliques qui portent les anciens noms et qui pointent vers les nouveaux fichiers de périphériques.
Avec devfsd, vous pouvez aussi attribuer les permissions, créer de nouveaux périphériques, définir des actions, etc. Tout ceci est décrit dans le prochain chapitre. 3. Administrer l'arborescence des périphériques Lorsque vous modifiez le fichier /etc/devfsd.conf et que vous voulez que les modifications soient prises en compte dans votre système, vous ne devez pas redémarrer votre machine. Suivant ce que vous voulez, vous pouvez utiliser l'un des deux signaux suivants : SIGHUP entraîne une relecture du fichier de configuration par devfsd, un rechargement des objets partagés et la génération des événements enregistrés pour chacun des « i-nodes » feuilles dans l'arbre des périphériques. SIGUSR1 produira le même résultat, mais ne générera pas le « REGISTER » d'événements. Pour émettre un signal, utilisez simplement les commandes kill ou killall de la façon suivante :
Supprimer les liens symboliques de compatibilité
Si vous ne voulez plus des liens de compatibilité du répertoire /dev dans votre système Gentoo (qui sont activés par défaut), éditez le fichier /etc/devfsd.conf et supprimez les deux lignes suivantes :
Vous devez redémarrer votre système pour que les modifications soient prises en compte. Supprimer la fonctionnalité d'autochargement Lorsque que vous charger un module, devfs crée automatiquement les fichiers périphériques. Si vous ne voulez pas ce type de comportement, supprimez la ligne suivante de votre fichier /etc/devfsd.conf :
4. Entrées relatives aux permissions Attribuer/modifier les permissions avec devfsd
Si vous voulez attribuer les permissions en utilisant le fichier /etc/devfsd.conf, utilisez la syntaxe présentée dans l'exemple suivant :
Le second champ représente le groupe de périphériques, commençant par /dev. C'est une expression rationnelle qui permet de sélectionner différents fichiers de périphériques en une seule règle. Le quatrième champ représente le propriétaire du fichier de périphérique et le cinquième contient les permissions pour le fichier de périphérique. Établir les permissions manuellement et faire que devfs les enregistre Voilà le comportement par défaut d'un système Gentoo : si vous utilisez les commandes chown (« CHange OWNer ») et chmod (« CHange MODe ») pour modifier les droits de certain fichiers de périphériques, devfsd enregistrera immédiatement l'information afin qu'elle persiste lors des prochains redémarrages. Ceci vient du fait que le fichier /etc/devfsd.conf contient les lignes suivantes :
En d'autres termes, les fichiers de périphériques modifiés sont copiés dans /lib/dev-state dès que les modifications sont réalisées et sont recopiés dans /dev lors du démarrage du système. Une autre possibilité est de monter /lib/dev-state sur /dev au démarrage. Pour faire ceci, vous devez être sûr que devfs n'est pas monté automatiquement (vous devrez peut-être recompiler votre noyau pour que cela ne soit pas le cas) et que /dev/console existe. Ensuite, quelque part au début des scripts de démarrage de votre système, vous placerez :
Pour plus d'informations sur devfs, voilà quelques liens utiles. La page man de devfs.conf donne la syntaxe du fichier /etc/devfsd.conf. Pour la voir, tapez man devfsd.conf. La FAQ devfs contient des informations au sujet du cœur de la structure de devfs et explique comment les pilotes peuvent supporter devfs. La revue LinuxJournal a publié un article intéressant intitulé devfs for Management and Administration. Daniel Robbins a écrit un ensemble d'articles pour le DeveloperWorks d'IBM à propos des systèmes de fichiers avancés. Trois d'entre eux parlent de devfs, voici leur titre : Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|