perso ... je suis un vieux de la vieille ... et j ai du mal a me mettre a jour ... ma seconde distribe etait une patate; ma premiere etait une slak de 1995 ... bref ... pour moi, quand on veut acceder au matos, c est /dev, et parfois, /proc. Mais depuis quelques annees, y a udev, devfs, procfs ... et j y capte rien.
Qu est ce que devfs et udev, quelle est la difference ? A quoi ca sert ? dans quelles dists c est utilise ? y as t il d autres methodes pour acceder aux devices ?
est ce que procfs est indispensable pour monter /proc, ou est une service suplementaire du pepin ?
j ai beau google et lire la doc du pepin, je capte assez mal ...
Forum Linux.général qu est ce que udev ? devfs ?
7
nov.
2004
# virtual filesystem
Posté par Raphael Monrouzeau . É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.
[^] # Re: virtual filesystem
Posté par Edouard Gomez (site web personnel) . Évalué à 5.
Oui, le code etait sujet à pas mal de racing conditions, et à des modprobe storms. En gros, comme l'ouverture d'un inode /dev/truc spawnait un modprobe pour charger le module adequat, si un process ouvrait sauvagement un device plein de fois, il arrivait que le noyau lance plusieurs modprobe en parallele... rien de bon
Mais le point le plus bloquant concernant devfs, c'est le fait que le mainteneur est injoignable, et personne n'est en mesure de reprendre le code (surtout un manque d'envie).
Greg KH s'est donc dis que grace a hotplug[1] + sysfs[2] et un daemon udevd serialisant les evenements hotplug[3], il etait en mesure de "peupler" /dev dynamiquement un peu comme devfs le faisait, mais cette fois ci uniquement coté userspace. Cependant udev n'est pas equivalent a devfs, en particulier, udev ne charge pas les modules a l'ouverture de l'inode du device (car le module n'etant pas chargé, aucun evennement hotplug n'est généré, donc aucun appel a udev n'est fait)... Voila voila.
Il y avait une conférence enregistrée en MPEG4 où Greg KH expliquait tout çà, je n'ai malheureusement pas l'url dans mes signets. Peut etre quelqu'un pourra la poster.
[1] chaque module détectant des changements d'état parmi les devices qu'il prend en charge lance /sbin/hotplug, en fait `cat /proc/sys/kernel/hotplug` en placant des variables d'environnement adequat... le reste est fait en userspace, montage d'un volume, mise en place des droits, creation d'un symlink /dev/mon_jukebox, etc...
[2] filesystem virtuel habituelment monté sur /sysfs qui représente le matériel géré par le noyau sous une forme arborescente logique et présentant l'état de chaque device.
[3] udevd est en gros une sorte de fifo à evennements hotplug, et qui en fonction des regles contenues dans /etc/udev.d/* cree les bons noeuds dans /dev
[^] # Re: virtual filesystem
Posté par durandal . Évalué à 3.
(Lien direct : http://mirror.switch.ch/sucon-04/greg_kh-udev.avi(...))
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.