Gentoo Logo

Avertissement : Ce document n'est plus valide ou plus maintenu.


Guide Devfs (Device File System, système de fichiers des périphériques)

Table des matières :

1.  Qu'est-ce que devfs ?

Le (bon ?) vieux temps

Attention : devfs est désuet et a disparu du noyau 2.6 depuis la version 2.6.13. Si vous utilisez un noyau 2.6, vous devriez passer à udev. Veuillez consulter notre Guide udev pour en savoir plus.

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 :

Exemple de code 1.1 : Obtenir des informations sur un fichier périphérique

# ls -l /dev/hda
brw-rw----    1 root     disk       3,   0 Jul  5  2000 /dev/hda

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).

Les problèmes

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.

Les solutions

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, le grand vainqueur ?

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

Répertoires

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 ! :)

Note : Vous pouvez aussi utiliser des noms de fichiers de périphériques plus proches des environnements de type Unix pour les disques durs, comme c0b0t0u0p2. Ils peuvent se situer dans /dev/ide/hd, /dev/scsi/hd, etc.

Pour vous donner une idée de l'arborescence, voilà une liste des répertoires que j'ai sur mon ordinateur portable :

Exemple de code 2.1 : Répertoires dans /dev

cdroms/     cpu/        discs/          floppy/
ide/        input/      loop/           misc/
netlink/    printers/   pts/            pty/
scsi/       sg/         shm/            sound/
sr/         usb/        vc/             vcc/

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.

Exemple de code 2.2 : Liens symboliques créés

$ ls -l /dev/hda4
lr-xr-xr-x    1 root   root      33 Aug 25 12:08 /dev/hda4 -> ide/host0/bus0/target0/lun0/part4

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

Redémarrer devfsd

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 :

Exemple de code 3.1 : Envoyer le signal SIGHUP à devfsd

# kill -s SIGHUP `pidof devfsd`
ou
# killall -s SIGHUP devfsd

Supprimer les liens symboliques de compatibilité

Attention : Actuellement, Gentoo ne peut être utilisé sans 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 :

Exemple de code 3.2 : /etc/devfsd.conf pour la compatibilité avec le schéma existant

# Commentez les deux lignes suivantes pour ne plus avoir les liens
# symboliques de compatibilité avec l'ancien mode de fonctionnement.
REGISTER        .*  MKOLDCOMPAT
UNREGISTER      .*  RMOLDCOMPAT

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 :

Exemple de code 3.3 : /etc/devfsd.conf et la fonction d'autochargement

LOOKUP      .*  MODLOAD

4.  Entrées relatives aux permissions

Attribuer/modifier les permissions avec devfsd

Important : Ces instructions sont valides à condition que pam_console soit désactivé dans /etc/pam.d/system-auth. Si vous activez pam_console, PAM aura alors le dernier mot concernant la gestion des permissions. Vous ne devriez de toute façon pas utiliser pam_console, puisqu'il a été retiré de l'arbre Portage.

Si vous voulez attribuer les permissions en utilisant le fichier /etc/devfsd.conf, utilisez la syntaxe présentée dans l'exemple suivant :

Exemple de code 4.1 : Gestion des permissions dans /etc/devfsd.conf

REGISTER    ^cdroms/.*  PERMISSIONS root.cdrom 0660

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 :

Exemple de code 4.2 : Permissions dans /etc/devfsd.conf

REGISTER        ^pt[sy]/.*   IGNORE
CHANGE          ^pt[sy]/.*   IGNORE
CREATE          ^pt[sy]/.*   IGNORE
DELETE          ^pt[sy]      IGNORE
REGISTER        ^log         IGNORE
CHANGE          ^log         IGNORE
CREATE          ^log         IGNORE
DELETE          ^log         IGNORE
REGISTER        .*           COPY    /lib/dev-state/$devname $devpath
CHANGE          .*           COPY    $devpath /lib/dev-state/$devname
CREATE          .*           COPY    $devpath /lib/dev-state/$devname
DELETE          .*           CFUNCTION GLOBAL unlink
/lib/dev-state/$devname
RESTORE         /lib/dev-state

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 :

Exemple de code 4.3 : Monter /lib/dev-state sur /dev

mount --bind /dev /lib/dev-state
mount -t devfs none /dev
devfsd /dev

5.  Sources d'information

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 :



Imprimer

Dernière mise à jour le 15 novembre 2007

La version originale de cette traduction n'est plus maintenue

Résumé : Grâce à ce document, vous saurez ce qu'est vraiment devfs et comment il fonctionne.

Sven Vermeulen
Auteur

Seemant Kulleen
Relecteur

Gérald Fenoy
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.