Au début (il y a longtemps sous Unix), les programmes découvraient les processus en cours d'exécution sur le système en lisant directement les structures de processus à partir de la mémoire du noyau (en ouvrant /dev/mem et en interprétant directement les données brutes). C'est ainsi que fonctionnaient les toutes premières commandes 'ps'. Au fil du temps, certaines informations ont été rendues disponibles via des appels système.
Cependant, c'est une mauvaise forme d'exposer les données système directement à l'espace utilisateur via /dev/mem, et désagréable de créer constamment de nouveaux appels système chaque fois que vous vouliez exporter de nouvelles données de processus, et donc une nouvelle méthode a été créée pour accéder aux données structurées des applications de l'espace utilisateur afin de connaître les attributs de processus. C'était le système de fichiers /proc. Avec /proc, les interfaces et les structures (répertoires et fichiers) pouvaient rester identiques, même si les structures de données sous-jacentes du noyau changeaient. C'était beaucoup moins fragile que le système précédent, et il évoluait mieux.
Le système de fichiers /proc a été conçu à l'origine pour publier des informations sur les processus et quelques attributs système clés, requis par 'ps', 'top', 'free' et quelques autres utilitaires système. Cependant, parce qu'il était facile à utiliser (à la fois du côté du noyau et du côté de l'espace utilisateur), il est devenu un dépotoir pour toute une gamme d'informations système. De plus, il a commencé à gagner des fichiers en lecture/écriture, à utiliser pour ajuster les paramètres et contrôler le fonctionnement du noyau ou de ses différents sous-systèmes. Cependant, la méthodologie de mise en œuvre des interfaces de contrôle était ad-hoc, et /proc est rapidement devenu un gâchis emmêlé.
Le système de fichiers sysfs (ou /sys) a été conçu pour ajouter de la structure à ce gâchis et fournir un moyen uniforme d'exposer les informations système et les points de contrôle (attributs système et pilote configurables) à l'espace utilisateur à partir du noyau. Désormais, la structure du pilote dans le noyau crée automatiquement des répertoires sous /sys lorsque les pilotes sont enregistrés, en fonction du type de pilote et des valeurs de leurs structures de données. Cela signifie que les pilotes d'un type particulier auront tous les mêmes éléments exposés via sysfs.
De nombreuses informations système et points de contrôle hérités sont toujours accessibles dans /proc, mais tous les nouveaux bus et pilotes doivent exposer leurs informations et points de contrôle via sysfs.
Quelle est la différence entre procfs et sysfs ?
proc
est l'ancien, il est plus ou moins sans règles et sans structure. Et à un moment donné, il a été décidé que proc
était un peu trop chaotique et une nouvelle voie était nécessaire.
Alors sysfs
a été créé, et les nouveaux éléments qui ont été ajoutés ont été placés dans sysfs
comme les informations sur l'appareil.
Donc, dans un certain sens, ils font la même chose, mais sysfs
est un peu plus structuré.
Pourquoi sont-ils conçus comme des systèmes de fichiers ?
La philosophie UNIX nous dit que tout est un "fichier", donc il a été créé pour se comporter comme des fichiers.
Si je comprends bien, proc est juste quelque chose pour stocker les informations immédiates concernant les processus en cours d'exécution dans le système.
Ces pièces ont toujours été là et elles ne seront probablement jamais déplacées dans sysfs
.
Mais il y a plus de vieux trucs que vous pouvez trouver dans proc
, qui n'a pas été déplacé.
procfs autorise le file_operations
arbitraire , sysfs est plus restreint
-
les entrées procfs reçoivent un
file_operations
struct, qui contient des pointeurs de fonction qui déterminent ce qui arrive à chaque appel système basé sur un fichier, par ex.open
,read
,mmap
, etc., et vous pouvez prendre des mesures arbitraires à partir de ceux-ci.Exemples minimaux :
- Comment
/proc/*
travailler? | Super utilisateur proc_create()
exemple pour le module noyau | Débordement de pile
- Comment
-
sysfs est plus restreint dans les sens suivants :
- vous n'implémentez que deux méthodes
show
etstore
, que Linux utilise pour implémenteropen
,close
,read
,write
etlseek
pour toi. Voir aussi :Comment attacher des opérations de fichier à l'attribut sysfs dans le pilote de plate-forme ? | Débordement de pile - étroitement couplé avec
kobject
Exemple minimal :comment créer un attribut de classe sysfs simple dans le noyau Linux v3.2 | Débordement de pile
- vous n'implémentez que deux méthodes