Tu vois ce qu'est un système de fichiers virtuel ?
Quand tu fais un opendir "/chemin/vers/un/dossier" tu reçois une liste des fichiers se trouvant dans ce dossier, et le opendir est spécifique au système de fichiers utilisé.
Pour /proc par exemple, tu as monté le device none (ou proc, ou truc) en procfs sur /proc. Enfin normalement, c'est écrit dans ton fstab.
Donc tous les open, read, write, opendir (getdents) ... de "/proc/tout/ce/qu'on/veut" seront ceux de procfs.
Et procfs génère ses informations à la volée (à partir de la liste de processus du kernel entre autres). Il ne va jamais lire sur le disque, c'est ce qu'on appelle un système de fichiers virtuel, d'ailleurs il n'a pas besoin de device (tu peux mettre ce que tu veux).
Oui procfs est indispensable pour monter /proc, tu peux même monter en procfs sur /ailleurs/procs et en même temps.
Devfs est un système de fichiers virtuel aussi.
Quand tu écris un module (disons le module device_mod) tu l'enregistres pour un major et certains minor.
C'est à dire qu'un open (read, write ...) sur un fichier de type device qui porte ce major et un de ces minors appellera le open (read, write ...) de ton module.
Et tu peux aussi l'enregistrer pour un nom de fichier (e.g. misc/device).
Maintenant si tu as monté en devfs sur le dossier /truc, essayer d'accéder (open) à /truc/misc/device chargera le module device_mod.
Et le module device_mod créera le fichier /truc/misc/device avec les bons major et minor.
En plus devfs a une toute autre manière (que personnellement je préfère) de nommer les devices.
Dernière chose sur devfs il est souvent accompagné de devfsd (même si ce n'est pas obligatoire) car devfs, donc le kernel, ne se rappelle pas d'un boot sur l'autre les permissions spéciales que tu avais pu accorder sur tel ou tel device.
Le démon devfsd permet d'attribuer des permissions dès la création des devices, de gérer des liens symboliques pour par exemple rester compatible avec l'ancien système de nommage ...
udev est différent.
il n'est pas situé dans le kernel. Mais le kernel le lance au moment de la détection (ou du chargement d'un module?) d'un matériel. Plus précisément il lance /sbin/hotplug qui lui lancera udev.
Suivant ses arguments et un fichier de conf udev va créer les devices à la demande avec les bons droits.
C'est plus modulaire car il permet d'utiliser les noms qu'on veut (et moi décidemment j'aime bien les noms devfs). Ca fait moins de code éxécuté en kernel, et il parait que le code de devfs était pas super en plus.
# virtual filesystem
Posté par Raphael Monrouzeau . En réponse au message qu est ce que udev ? devfs ?. Évalué à 6.
Quand tu fais un opendir "/chemin/vers/un/dossier" tu reçois une liste des fichiers se trouvant dans ce dossier, et le opendir est spécifique au système de fichiers utilisé.
Pour /proc par exemple, tu as monté le device none (ou proc, ou truc) en procfs sur /proc. Enfin normalement, c'est écrit dans ton fstab.
Donc tous les open, read, write, opendir (getdents) ... de "/proc/tout/ce/qu'on/veut" seront ceux de procfs.
Et procfs génère ses informations à la volée (à partir de la liste de processus du kernel entre autres). Il ne va jamais lire sur le disque, c'est ce qu'on appelle un système de fichiers virtuel, d'ailleurs il n'a pas besoin de device (tu peux mettre ce que tu veux).
Oui procfs est indispensable pour monter /proc, tu peux même monter en procfs sur /ailleurs/procs et en même temps.
Devfs est un système de fichiers virtuel aussi.
Quand tu écris un module (disons le module device_mod) tu l'enregistres pour un major et certains minor.
C'est à dire qu'un open (read, write ...) sur un fichier de type device qui porte ce major et un de ces minors appellera le open (read, write ...) de ton module.
Et tu peux aussi l'enregistrer pour un nom de fichier (e.g. misc/device).
Maintenant si tu as monté en devfs sur le dossier /truc, essayer d'accéder (open) à /truc/misc/device chargera le module device_mod.
Et le module device_mod créera le fichier /truc/misc/device avec les bons major et minor.
En plus devfs a une toute autre manière (que personnellement je préfère) de nommer les devices.
Dernière chose sur devfs il est souvent accompagné de devfsd (même si ce n'est pas obligatoire) car devfs, donc le kernel, ne se rappelle pas d'un boot sur l'autre les permissions spéciales que tu avais pu accorder sur tel ou tel device.
Le démon devfsd permet d'attribuer des permissions dès la création des devices, de gérer des liens symboliques pour par exemple rester compatible avec l'ancien système de nommage ...
udev est différent.
il n'est pas situé dans le kernel. Mais le kernel le lance au moment de la détection (ou du chargement d'un module?) d'un matériel. Plus précisément il lance /sbin/hotplug qui lui lancera udev.
Suivant ses arguments et un fichier de conf udev va créer les devices à la demande avec les bons droits.
C'est plus modulaire car il permet d'utiliser les noms qu'on veut (et moi décidemment j'aime bien les noms devfs). Ca fait moins de code éxécuté en kernel, et il parait que le code de devfs était pas super en plus.
Voilà pour un court résumé, plein de fautes.