Ulrich Dangel explique très bien la différence entre devtmpfs et udev.
Qu'en est-il de sysfs ?
Je comprends que le noyau utilise sysfs pour exporter les nœuds de périphérique vers l'espace utilisateur à utiliser par udev. Alors devtmpfs et sysfs sont les mêmes? Si oui, pourquoi utilisent-ils des noms différents ? Si non, quelle est la vraie différence entre sysfs et devtmpfs ?
Réponse acceptée :
le noyau utilise sysfs pour exporter les nœuds de périphérique vers l'espace utilisateur à utiliser par udev
Non. Sysfs ne contient pas de nœuds de périphérique. Sysfs contient principalement des fichiers qui fournissent des informations sur les appareils, ainsi que certains fichiers qui permettent aux processus de contrôler le fonctionnement des appareils. Mais pour la plupart, les appareils ne peuvent pas être utilisés via ce que sysfs fournit.
Prenons un disque dur, par exemple. Il y a un répertoire pour cela quelque part sous /sys/devices , avec un chemin qui dépend de la manière dont il est connecté à l'ordinateur (par exemple, /sys/devices/pci0000:00/… pour un disque connecté à un contrôleur connecté au bus PCI principal de l'ordinateur). Dans ce répertoire, vous pouvez trouver diverses informations telles que sa taille, s'il est amovible, son état d'alimentation, etc. Il existe également des sous-répertoires pour les partitions. Mais il n'y a rien là-dedans qui donne accès au contenu du disque. Ailleurs dans /sys , il existe des liens symboliques vers le répertoire correspondant à ce disque :dans /sys/block , dans /sys/class/block , etc. Mais toujours rien pour accéder au contenu du disque.
Dans /dev , l'entrée pour le disque est un fichier spécial :un périphérique bloc. Ce fichier permet aux processus de lire et d'écrire le contenu du disque. (Bien que pour un disque, cela ne se produise généralement pas ; à la place, le contenu du disque - ou d'une partition - est monté, de sorte que le noyau accède au périphérique, pas les processus.)
Les fichiers de périphérique permettent d'effectuer certaines opérations autres que la lecture et l'écriture de contenu via ioctl. Il serait possible de fournir toutes les informations et interfaces de contrôle fournies par sysfs via ioctl sur le fichier de périphérique. Cependant cela serait moins pratique pour plusieurs raisons :
- Avec des fichiers séparés dans
/sys, les autorisations peuvent être définies de manière précise. Avec un seul fichier par appareil dans/dev, c'est tout ou rien. - Les fichiers séparés peuvent être lus et écrits facilement par les applications. Vous pouvez simplement utiliser
catouecho. Avec ioctl, c'est beaucoup plus difficile :il n'y a pas d'interface shell, souvent pas d'interface dans d'autres langages de haut niveau. - Avec ioctl, la commande doit être encodée sous la forme d'un nombre plutôt que d'un nom, et le format des arguments doit être défini au niveau binaire. L'utilisation de noms et de formats de texte simples facilite l'écriture de logiciels.
Dans l'autre sens, il serait possible de donner accès au contenu de l'appareil via un fichier dans sysfs. Mais cela nécessiterait un travail supplémentaire dans le noyau :sysfs est conçu principalement pour servir de petits fichiers et des liens symboliques, et sans l'ioctl support que les applications existantes attendent. Je ne pense pas qu'il y aurait un avantage significatif à étendre sysfs pour prendre en charge les types d'appareils existants, d'où l'existence continue de fichiers d'appareils.
Sysfs est automatiquement rempli par le noyau, reflétant les périphériques réellement disponibles en temps réel. La signification d'un fichier dans sysfs vient de son chemin, qui est choisi par le pilote qui fournit ce fichier. /dev fonctionne différemment :la signification d'un fichier provient du type de fichier de périphérique (bloc ou caractère) et de ses numéros majeur et mineur (c'est ce que ls -l listes au lieu de la taille de fichier pour un périphérique). Traditionnellement, /dev était statique, avec des fichiers de périphérique créés lors de l'installation du système ; mais cela ne fonctionne pas si bien lorsque les appareils peuvent être branchés à chaud, d'où le souhait d'un /dev dynamique qui reflète les appareils connectés en temps réel.
Linux a traversé plusieurs itérations d'un /dev dynamique . Linux 2.4 a devfs, où le noyau crée automatiquement des entrées pour refléter les périphériques connectés. Mais ce n'était pas si agréable, car il a codé en dur les politiques de nommage et d'autorisation des périphériques dans le noyau, il a donc été remplacé par le programme utilisateur udev pour gérer la politique, et /dev sur un simple système de fichiers tmpfs (un système de fichiers en mémoire sans signification particulière pour le noyau). Et puis devfs a fait un retour partiel, avec devtmpfs, qui est une instance de tmpfs où les entrées pour les périphériques disponibles sont automatiquement créées par le noyau, mais udev fait toute la gestion qu'il veut en plus.