C'est en fait assez simple, du moins si vous n'avez pas besoin des détails de mise en œuvre.
Tout d'abord, sous Linux, tous les systèmes de fichiers (ext2, ext3, btrfs, reiserfs, tmpfs, zfs, ...) sont implémentés dans le noyau. Certains peuvent décharger le travail sur le code utilisateur via FUSE, et certains ne se présentent que sous la forme d'un module de noyau (le ZFS natif est un exemple notable de ce dernier en raison des restrictions de licence), mais dans tous les cas, il reste un composant du noyau. C'est une base importante.
Lorsqu'un programme veut lire à partir d'un fichier, il émet divers appels à la bibliothèque système qui finissent par se retrouver dans le noyau sous la forme d'un open() , read() , close() séquence (éventuellement avec seek() jeté pour faire bonne mesure). Le noyau prend le chemin et le nom de fichier fournis et, via le système de fichiers et la couche d'E/S du périphérique, les traduit en requêtes de lecture physiques (et dans de nombreux cas également en requêtes d'écriture - pensez par exemple à des mises à jour temporelles) vers un stockage sous-jacent.
Cependant, il n'est pas nécessaire de traduire ces demandes spécifiquement en physique, persistant stockage . Le contrat du noyau est que l'émission de cet ensemble particulier d'appels système fournira le contenu du fichier en question . L'endroit exact où se trouve le "fichier" dans notre domaine physique est secondaire par rapport à cela.
Le /proc est généralement monté ce qu'on appelle procfs . Il s'agit d'un type de système de fichiers spécial, mais comme il s'agit d'un système de fichiers, ce n'est vraiment pas différent de, par exemple. un ext3 système de fichiers monté quelque part. Ainsi, la requête est transmise au code du pilote du système de fichiers procfs, qui connaît tous ces fichiers et répertoires et renvoie des informations particulières à partir des structures de données du noyau .
La "couche de stockage" dans ce cas est les structures de données du noyau, et procfs fournit une interface propre et pratique pour y accéder. Gardez à l'esprit que le montage de procfs à /proc est simplement une convention ; vous pourriez tout aussi bien le monter ailleurs. En fait, cela se fait parfois, par exemple dans les prisons chroot lorsque le processus qui s'y exécute a besoin d'accéder à /proc pour une raison quelconque.
Cela fonctionne de la même manière si vous écrivez une valeur dans un fichier; au niveau du noyau, cela se traduit par une série de open() , seek() , write() , close() appels qui sont à nouveau transmis au pilote du système de fichiers ; encore une fois, dans ce cas particulier, le code procfs.
La raison particulière pour laquelle vous voyez file retour empty est que de nombreux fichiers exposés par procfs sont exposés avec une taille de 0 octet. La taille de 0 octet est probablement une optimisation du côté du noyau (de nombreux fichiers dans /proc sont dynamiques et peuvent facilement varier en longueur, peut-être même d'une lecture à l'autre, et calculer la longueur de chaque fichier sur chaque répertoire lu serait potentiellement très coûteux). D'après les commentaires de cette réponse, que vous pouvez vérifier sur votre propre système en exécutant strace ou un outil similaire, file émet d'abord un stat() appel pour détecter tout fichier spécial, puis en profite pour, si la taille du fichier est signalée comme 0, abandonner et signaler le fichier comme étant vide.
Ce comportement est en fait documenté et peut être surchargé en spécifiant -s ou --special-files sur le file appel, bien que, comme indiqué dans la page de manuel, cela puisse avoir des effets secondaires. La citation ci-dessous provient de la page de manuel du fichier BSD 5.11, datée du 17 octobre 2011.
Normalement, file essaie seulement de lire et de déterminer le type des fichiers d'arguments que stat(2) signale comme des fichiers ordinaires. Cela évite les problèmes, car la lecture de fichiers spéciaux peut avoir des conséquences particulières. Spécifier le
-sL'option file lit également les fichiers d'arguments qui sont des fichiers spéciaux de type bloc ou caractère. Ceci est utile pour déterminer les types de système de fichiers des données dans les partitions de disque brutes, qui sont des fichiers spéciaux en mode bloc. Cette option fait également en sorte que le fichier ignore la taille du fichier comme indiqué par stat(2) car sur certains systèmes, il signale une taille nulle pour les partitions de disque brutes.
Dans ce répertoire, vous pouvez contrôler la façon dont le noyau affiche les périphériques, ajuster les paramètres du noyau, ajouter des périphériques au noyau et les supprimer à nouveau. Dans ce répertoire, vous pouvez visualiser directement l'utilisation de la mémoire et les statistiques d'E/S.
Vous pouvez voir quels disques sont montés et quels systèmes de fichiers sont utilisés. En bref, chaque aspect de votre système Linux peut être examiné à partir de ce répertoire, si vous savez ce qu'il faut rechercher.
Le /proc répertoire n'est pas un répertoire normal. Si vous deviez démarrer à partir d'un CD de démarrage et regarder ce répertoire sur votre disque dur, vous le verriez comme étant vide. Lorsque vous le regardez sous votre système d'exploitation normal, il peut être assez volumineux. Cependant, il ne semble pas utiliser d'espace disque. C'est parce qu'il s'agit d'un système de fichiers virtuel.
Depuis le /proc le système de fichiers est un système de fichiers virtuel et réside en mémoire, un nouveau /proc Le système de fichiers est créé à chaque redémarrage de votre machine Linux.
En d'autres termes, c'est juste un moyen de jeter un coup d'œil et de fouiller facilement dans les entrailles du système Linux via une interface de type fichier et répertoire. Lorsque vous regardez un fichier dans le /proc répertoire, vous regardez directement une plage de mémoire dans le noyau Linux et voyez ce qu'il peut voir.
Les couches du système de fichiers
Exemples :
- À l'intérieur du
/proc, il existe un répertoire pour chaque processus en cours d'exécution, nommé avec son ID de processus. Ces répertoires contiennent des fichiers contenant des informations utiles sur les processus, telles que :exe:qui est un lien symbolique vers le fichier sur le disque à partir duquel le processus a été lancé.cwd:qui est un lien symbolique vers le répertoire de travail du processus.wchan:qui, lorsqu'il est lu, renvoie le canal en attente sur lequel se trouve le processus.maps:qui, lorsqu'il est lu, renvoie les cartes mémoire du processus.
/proc/uptimerenvoie le temps de fonctionnement sous la forme de deux valeurs décimales en secondes, séparées par un espace :- le temps écoulé depuis le démarrage du noyau.
- la durée d'inactivité du noyau.
/proc/interrupts:Pour des informations relatives aux interruptions./proc/modules:Pour une liste de modules.
Pour des informations plus détaillées, voir man proc ou kernel.org.
Vous avez raison, ce ne sont pas de vrais fichiers.
En termes simples, c'est un moyen de parler au noyau en utilisant les méthodes normales de lecture et d'écriture de fichiers, au lieu d'appeler directement le noyau. C'est conforme à la philosophie "tout est un fichier" d'Unix.
Les fichiers en /proc n'existent physiquement nulle part, mais le noyau réagit aux fichiers que vous lisez et écrivez à l'intérieur, et au lieu d'écrire dans le stockage, il rapporte des informations ou fait quelque chose.
De même, les fichiers en /dev ne sont pas vraiment des fichiers au sens traditionnel (bien que sur certains systèmes les fichiers en /dev peuvent réellement exister sur le disque, ils n'auront pas grand-chose d'autre que le périphérique auquel ils se réfèrent) - ils vous permettent de parler à un périphérique en utilisant l'API d'E/S de fichier Unix normale - ou tout ce qui l'utilise, comme les shells