Comment fonctionne / proc / *?

Il y a beaucoup de fichiers dans /proc, comme /proc/cpuinfo, /proc/meminfo, /proc/deviceset ainsi de suite, qui, lorsqu'il est ouvert, les informations système de retour.

Ces fichiers ne semblent pas exister dans la réalité, leur exécution filene faisant qu’indiquer qu’ils sont vides.

$ file /proc/cpuinfo
/proc/cpuinfo: empty

Comment ces fichiers fonctionnent-ils exactement?

C'est en fait assez simple, du moins si vous n'avez pas besoin des détails de la 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 du travail sur le code utilisateur via FUSE, et d’autres ne se présentent que sous la forme d’un module de noyau ( ZFS natif est un exemple notable de ce dernier en raison de restrictions de licence), mais dans tous les cas, il reste un composant du noyau. Ceci est une base importante.

Lorsqu'un programme veut lire à partir d' un fichier, il publiera plusieurs appels à la bibliothèque du système qui finissent en fin de compte dans le noyau sous la forme d'un open(), read(), close()séquence (éventuellement avec seek()pour faire bonne mesure). Le noyau prend le chemin et le nom de fichier fournis et, au travers du système de fichiers et de la couche d'E / S du périphérique, les traduit en demandes de lecture physiques (et, dans de nombreux cas, également en demandes d'écriture - pensez par exemple à des mises à jour) sur un stockage sous-jacent.

Cependant, il n'est pas nécessaire de traduire ces demandes spécifiquement en stockage physique persistant . Le contrat du noyau stipule que l'émission de cet ensemble particulier d'appels système fournira le contenu du fichier en question . Où exactement dans notre royaume physique le "fichier" existe est secondaire à ceci.

On /procest 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, il n’est en réalité pas différent d’un ext3système de fichiers monté quelque part. Ainsi, la demande est transmise au code du pilote de 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 .

Dans ce cas, la "couche de stockage" correspond aux structures de données du noyau et procfsfournit une interface propre et pratique pour y accéder. Gardez à l'esprit que le montage de procfs à /procest simplement une convention; vous pourriez tout aussi facilement le monter ailleurs. En fait, cela est parfois fait, par exemple dans les jails chroot lorsque le processus qui y est exécuté doit avoir accès à / 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, qui se traduit par une série de open(), seek(), write(), close()appels qui se nouveau transmis au pilote de système de fichiers; encore une fois, dans ce cas particulier, le code procfs.

La raison particulière pour laquelle vous voyez filerevenir emptyest que beaucoup de fichiers exposés par procfs sont exposés avec une taille de 0 octet. La taille de 0 octet est probablement une optimisation côté noyau (la plupart des fichiers de / proc sont dynamiques et peuvent facilement varier en longueur, éventuellement même d’une lecture à l’autre, et calculer la longueur de chaque fichier à chaque lecture du répertoire potentiellement très cher). En passant par les commentaires de cette réponse, que vous pouvez vérifier sur votre propre système en exécutant strace ou un outil similaire, filelance d'abord un stat()appel pour détecter tout fichier spécial, puis en profite, si la taille du fichier est 0. , abandonnez et signalez que le fichier est vide.

Ce comportement est en fait documenté et peut être remplacé en spécifiant -sou --special-filessur l' fileinvocation, 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 relative au fichier BSD 5.11, datée du 17 octobre 2011.

Normalement, seul le fichier tente de lire et de déterminer le type de fichiers d'arguments pour lesquels les rapports stat (2) sont des fichiers ordinaires. Cela évite les problèmes, car la lecture de fichiers spéciaux peut avoir des conséquences particulières. En spécifiant l' -soption, le fichier lira également les fichiers d'arguments qui sont des fichiers spéciaux de bloc ou de 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 bloqués. Cette option permet également à file de ne pas tenir compte de la taille de fichier indiquée par stat (2) car, sur certains systèmes, elle indique une taille nulle pour les partitions de disque brutes.

Dans ce répertoire, vous pouvez contrôler la manière 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 voir 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 quoi chercher.

Le /procrépertoire n'est pas un répertoire normal. Si vous deviez démarrer à partir d'un CD de démarrage et consulter ce répertoire sur votre disque dur, vous verriez qu'il est 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 que c'est un système de fichiers virtuel.

Le /procsystème de fichiers étant un système de fichiers virtuel et résidant en mémoire, un nouveau /procsystème de fichiers est créé à chaque redémarrage de votre machine Linux.

En d’autres termes, c’est juste un moyen de regarder et de toucher facilement les entrailles du système Linux via une interface de type fichier et répertoire. Lorsque vous consultez un fichier dans le /procrépertoire, vous consultez directement une plage de mémoire du noyau Linux et voyez ce qu'il peut voir.

Les couches dans le système de fichiers

Exemples:

• À l'intérieur /proc, il existe un répertoire pour chaque processus en cours, nommé avec son ID de processus. Ces répertoires contiennent des fichiers contenant des informations utiles sur les processus, tels que:
  • exe: qui est un lien symbolique vers le fichier sur le disque à partir duquel le processus a été démarré.
  • 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 le processus est activé.
  • maps: qui, une fois lues, renvoie les cartes mémoire du processus.
• /proc/uptime renvoie la disponibilité sous 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 pendant laquelle le noyau a été inactif.
• /proc/interrupts: Pour des informations relatives aux interruptions.
• /proc/modules: Pour une liste de modules.

Pour plus d'informations, voir man proc ou kernel.org .

Vous avez raison, ce ne sont pas de vrais fichiers.

En termes simples, c’est un moyen de communiquer avec le noyau en utilisant les méthodes habituelles de lecture et d’écriture des fichiers, au lieu de l’appeler directement. Cela va dans le sens de la philosophie "tout est un fichier" d'Unix.

Les fichiers /procn’existent physiquement nulle part, mais le noyau réagit aux fichiers que vous avez lus et écrits, et au lieu d’écrire sur le stockage, il rapporte des informations ou fait quelque chose.

De même, les fichiers /devne sont pas vraiment des fichiers au sens traditionnel du terme (même si, sur certains systèmes, les fichiers /devpeuvent exister sur un disque, ils n'ont pas autre chose à dire, mais à quel périphérique ils font référence). Ils vous permettent de parler. vers un périphérique utilisant l'API d'E / S sur fichier Unix normale - ou tout ce qui l'utilise, comme des shells

À l'intérieur du /procrépertoire, il existe deux types de contenu, le premier répertoire numéroté et le second est le fichier d'informations système.

/procest un système de fichiers virtuel. Par exemple, si vous le faites ls -l /proc/stat, vous remarquerez qu'il a une taille de 0 octet, mais si vous exécutez «cat / proc / stat», vous verrez du contenu dans le fichier.

Faites un ls -l /proc, et vous verrez beaucoup de répertoires avec seulement des chiffres. Ces nombres représentent les ID de processus (PID). Les fichiers dans ce répertoire numéroté correspondent au processus avec ce PID particulier.

Certains fichiers disponibles sous /proccontiennent des informations système telles que cpuinfo, meminfo et loadavg.

Certaines commandes Linux lisent les informations à partir de ces /procfichiers et les affichent. Par exemple, la commande free lit les informations sur la mémoire à partir du /proc/meminfofichier, les formate et les affiche.

Pour en savoir plus sur les /procfichiers individuels , faites «man 5 FILENAME».

/proc/cmdline – Kernel command line
/proc/cpuinfo – Information about the processors.
/proc/devices – List of device drivers configured into the currently running kernel.
/proc/dma – Shows which DMA channels are being used at the moment.
/proc/fb – Frame Buffer devices.
/proc/filesystems – File systems supported by the kernel.
/proc/interrupts – Number of interrupts per IRQ on architecture.
/proc/iomem – This file shows the current map of the system’s memory for its various devices
/proc/ioports – provides a list of currently registered port regions used for input or output communication with a device
/proc/loadavg – Contains load average of the system
The first three columns measure CPU utilization of the last 1, 5, and 10 minute periods.
The fourth column shows the number of currently running processes and the total number of processes.
The last column displays the last process ID used.
/proc/locks – Displays the files currently locked by the kernel
Sample line:
1: POSIX ADVISORY WRITE 14375 08:03:114727 0 EOF
/proc/meminfo – Current utilization of primary memory on the system
/proc/misc – This file lists miscellaneous drivers registered on the miscellaneous major device, which is number 10
/proc/modules – Displays a list of all modules that have been loaded by the system
/proc/mounts – This file provides a quick list of all mounts in use by the system
/proc/partitions – Very detailed information on the various partitions currently available to the system
/proc/pci – Full listing of every PCI device on your system
/proc/stat – Keeps track of a variety of different statistics about the system since it was last restarted
/proc/swap – Measures swap space and its utilization
/proc/uptime – Contains information about uptime of the system
/proc/version – Version of the Linux kernel, gcc, name of the Linux flavor installed.

Exemple minimal exécutable

La meilleure façon de comprendre ces choses à mon avis est de jouer avec elles, voici donc un module du noyau qui crée une entrée procfs:

myprocfs.c

#include <linux/debugfs.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h> /* seq_read, seq_lseek, single_open, single_release */
#include <uapi/linux/stat.h> /* S_IRUSR */

static const char *filename = "lkmc_procfs";

static int show(struct seq_file *m, void *v)
{
    seq_printf(m, "abcd\n");
    return 0;
}

static int open(struct inode *inode, struct  file *file)
{
    return single_open(file, show, NULL);
}

static const struct file_operations fops = {
    .llseek = seq_lseek,
    .open = open,
    .owner = THIS_MODULE,
    .read = seq_read,
    .release = single_release,
};

static int myinit(void)
{
    proc_create(filename, 0, NULL, &fops);
    return 0;
}

static void myexit(void)
{
    remove_proc_entry(filename, NULL);
}

module_init(myinit)
module_exit(myexit)
MODULE_LICENSE("GPL");

et ensuite nous interagissons avec:

insmod procfs.ko
cat /proc/lkmc_procfs

et qui produit la sortie:

abcd

Dans cet exemple, nous voyons clairement que les procfichiers nous permettent d’implémenter arbitrairement des "appels système liés aux fichiers" tels que open, readet llseek.

Ces appels système peuvent ensuite être utilisés pour une communication arbitraire avec le noyau.

Par conséquent, ces fichiers n'ont pas besoin d'avoir rien à voir avec les fichiers réels dans les systèmes de fichiers, et c'est le cas pour la quasi-totalité d'entre eux.

Dans notre petit exemple par exemple, nous créons simplement un fichier inutile pour lequel nous readretournons toujours abcd\n.

Voici ma configuration entièrement automatisée de QEMU + Buildroot pour construire et jouer facilement et en toute sécurité avec ce module de noyau:

• commencer
• exemple de documentation procfs

Certaines autres interfaces similaires incluent:

• debugfs offre fondamentalement exactement la même interface mais indique une API moins stable, voici un exemple .

• Les périphériques de caractères sont également très similaires, mais les fichiers sont créés avec mknod, par exemple: https://unix.stackexchange.com/questions/37829/how-do-character-device-or-character-special-files-work/371758# 371758

• sysfs est une autre option plus restreinte, voir la réponse à cette question pour plus de détails: https://unix.stackexchange.com/questions/4884/what-is-the-difference-between-procfs-and-sysfs/382315#382315