- Mais qu'est-ce que c'est que ça ???
- Mais que veux-tu dire par dynamique ?
- devfs: l'implémentation au niveau noyau
- udev: l'implémentation au niveau utilisateur
Mais qu'est-ce que c'est que ça ???
Bonjour, je ne me suis pas présenté, je m'appelle /dev et je suis un répertoire très répandu sur les systèmes *nix et apparentés. Ma fonction: (attention si tu es newbie, ou si tu n'en as rien à foutre, ceci risque de te paraître superflu voire incompréhensible)
- présenter aux programmes utilisateurs la plupart du matériel installé sur la machine
- fournir une interface et des points d'accés au matériel pour les programmes utilisateurs
et enfin comme la philosophie Unix nous l'enseigne, présenter cette interface sous formes de fichiers (spéciaux, bien évidemment...) au monde extérieur, c'est-à-dire vous, utilisateurs chanceux d'un système *nix cohérent
On représente les périphériques à partir desquels on peut lire des données et sur lesquels on peut en écrire par des fichiers pour unifier les stratégies d'ouverture, de lecture et d'écriture, entre autres choses.
Par exemple, la commande suivante (attention ceci n'est pas à reproduire à la maison)
# cat /dev/zero > /dev/hda
va copier une série de 0 sur le périphérique /dev/hda à savoir le premier disque dur du premier contrôleur IDE.
Une façon plus tordue de "casser" sa config faisant appel aux fichiers de péripérique:
# dd if=/dev/zero of=/dev/hda bs=1 count=24
Pour les newbies: que fait précisément cette commande et pourquoi ça fait mal à Tux ?
Pour info, je paye une bière à celui qui me trouve la réponse (les geeks n'ont pas le droit de participer)
[Et moi, je suis un geek ? parce que je sais maintenant ! -- MitMit ]
![[NEW]](/wiki/crans-www/img/moin-new.png "[NEW]"){kind=small}
Une nouvelle page pour rigoler SystèmeLinux/CommandesCons (comme quoi, on reste humain quand on est geek)
Ne le faites pas, je nierais toute responsabilité pour une quelconque perte de données
Pour ceux qui auront préféré sauter la partie "technique": si y a pas de fichiers dans /dev, le système ne peut plus accéder à nombre de périphériques, donc à rien du tout en gros.
Mais que veux-tu dire par dynamique ?
En fait, selon l'*nix sur lequel je me trouve et la machine, mon poids varie:
- sur la plupart des Unix proprios, je suis assez svelte, en proportion au système m'accueillant et ne contenant que des chose utiles: je représente le matériel installé ni plus, ni moins
- sur Net BSD, et OpenBSD et la plupart des distributions Linux, je suis au contraire obèse, rempli de tous les devices possibles et imaginables: je me refère au pire cas et donc je dois pouvoir donner accés au plus inconnu des matériels.
Cependant, tous ces noeuds prennent de la place sur le disque dur (peu en terme d'espace mais un système de fichier ne peut abriter un nombre arbitraire de fichiers et c'est là que peut se trouver le hic). De plus, sur une système GNU/Linux comme Debian, l'utilsateur ne peut se référer à mon contenu pour connaître le matériel présent et reconnu par le système.
Un système comme GNU/Linux implémente cependant plusieurs moyens pour me remplir des fichiers périphériques présents sur le système: devfs et udev
devfs: l'implémentation au niveau noyau
La première tentative pour avoir un /dev rempli au fur et à mesure de l'utilisation d'une machine, date d'un certain temps: devfs. En gros, c'est un système de fichiers virtuel, pas on-disk comme ext3 ou reiserfs, qui est rempli par le noyau en présence du matériel détecté (si le driver correspondant est compilé sous forme de module, il faut le charger avec modprobe ou insmod).
Il utilise un "daemon", c'est-à-dire un service s'exécutant en tâche de fond, répondant au joli nom de devfsd. Il n'est utile que pour émuler les anciens noms ou garder les permissions.
Pour résumer, l'utilisation de devfs requiert 2 choses:
la présence de devfsd sur votre machine
le noyau doit supporter le système de fichier devfs (pour cela, je renvoie à la configuration basique d'un noyau :-p)
Sur une distribution Debian, simple comme bonjour, vous devez d'abord compiler un noyau, en activant le support de devfs et en cochant l'option "Mount at boot time" ou approchant
Ensuite, installez devfsd:
# aptitude install devfsd
A présent, vous devez configurer devfsd pour qu'il démarre au boot, sinon votre système est cuit
Pour cela, éditez /etc/default/devfsd, la syntaxe est claire, si je me rappelle bien et il suffit de remplacer un no par un yes.
Enfin, rebootez sur votre nouveau noyau et voilà !
udev: l'implémentation au niveau utilisateur
Certains hackers ont exprimé récemment, certaines critiques concernant devfs: défaut d'implémentation, bogues insolubles, situations de concurrence insolubles et comble pour une portion du code du noyau Linux, absence de mainteneur (pour la petite histoire, sachez que l'auteur de devfs, Richard Gooch, a complètement disparu de la scène Linux Kernel, dégoûté sans doute du traitement que lui a fait subir l'actuel mainteneur du VFS ) devfs a ainsi été marqué obsolete (et déconseillé) depuis la sortie du kernel version 2.6.0. Les principales reproches à devfs tiennent à cela: les noms des devices nodes, ainsi que leur utilisation n'a rien à voir avec les mécanismes internes du noyau, au contraire, l'utilisateur doit pouvoir appeler /dev/homosexuel son 1er disque dur
Pour cela, récemment, un projet a vu le jour et semble arrivé à maturité: udev est le fruit du travail de nombreux développeurs dont Greg Kroah-Hartman, mainteneur de l'USB dans le noyau Linux, Robert Love, à qui l'on doit le remaniage du support de kernel preemption d'abord implémenté par Ingo Molnar, et enfin Kay Sievers, que l'on ne peut pas oublier, le patcheur qui patche plus vite que son ombre.
Basiquement, udev utilise les informations fournies par sysfs, un nouveau système de fichier virtuel introduit dans la branche 2.5, pour déterminer le matériel présent, quel fichier spécial créer dans /dev, et quand le créer. Il est évident, que l'utilisation d'un noyau 2.6 est requise, mais comme on vous le dira et comme le remarquerez sans doute c'est un moindre mal :p.
(Et bien sûr, les douillets qui restent en Debian stable ne tireront rien de leur système antique)
Configuration noyau
La seule option requise, pour lequel l'utilisateur est appelé à faire un choix, est CONFIG_HOTPLUG En effet, udev sera exécuté à chaque évènement hotplug généré par le noyau: clé USB, que l'on branche, module de son chargé automatiquement...
Il est également conseillé de compiler tmpfs.
Installation et configuration d'udev
Le fonctionnement d'udev a légèrement évolué depuis la première version. Maintenant, sachez seulement, qu'un daemon, udevd tourne en permanence en attente d'ordre de création (ou de destruction) de fichiers spéciaux, que lui envoient udev par le biais d'udevsend. Le package contient également un exécutable du nom d'udevstart, qui remplit le /dev initialement vide au boot. En effet, udev n'est exécuté que quand quelque chose dans la configuration matérielle change, pas au boot :-/
L'installation est des plus simples sur Debian GNU/Linux:
# aptitude install udev libsysfs1
J'ai rajouté le paquet libsysfs1 car la dernière version uploadée dans unstable, manque cette dépendance et udev ne marchera pas, sans elle. Si udev n'est pas à ce jour en testing, cela ne devrait plus tarder.
![/!\](/wiki/crans/img/alert.png "/!\"){kind=small}
udev ne créera les device nodes que pour les drivers supportant sysfs; peu de drivers du noyau Linux, sont dans ce cas. Dans mon cas, j'utilise une Debian sur mon iBook Early 2003: je suis obligé d'utiliser le framebuffer pour avoir un joli X :-/. Sachant que les divers drivers de framebuffer ne supportent pas (ou plus) l'infrastructure sysfs, les noeuds /dev/fb* ne seront pas créés au boot. Pour palier à ce genre de petits désagréments, le mainteneur du paquet Debian, Marco D'Itri a introduit le fichier de conf /etc/udev/links.conf. Son format est simple et clair: pour créer les noeuds des framebuffers, les lignes suivantes suffisent:
D fb M fb/0 c 29 0 L fb0 fb/0 ...
cette solution n'est que provisoire
Pour les utilisateurs de Mac, un autre noeud de périphérique n'est pas créé pas udev; adb est cependant nécessaire pour activer tout support de sleep mode et gestion d'énergie via pmud
M adb c 56 0
Une fois toutes ces informations bien comprises, il faut maintenant rebooter le système (lancer le script d'initialisation d'udev peut créer quelques surprises, sans un reboot préalable 
Si jamais un problème survenait, sachez dans le cas de Debian,que le /dev initial, plein à craquer est disponible dans le répertoire /etc/udev/.dev.
Un document qu'il est bien pour écrire des règles : Writing udev rules
Pour de plus amples informations, adressez vos questions à la mailing-liste Hotplug-Devel linux-hotplug-devel@lists.sourceforge.net ou à moi, j'essaierai de vous répondre dans la mesure du possible et de mes connaissances.
