Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me
faire un petit discours en direct :-) ) qui explique de manière
compréhensible et relativement détaillée comment fonctionnent les
différentes manières de gerer /dev ?
Je lis à différents endroits à peu près tout et son contraire (fonction
de l'âge de la page, des connaissances de son auteur, du noyau qu'il
utilise, de son église...) sur quelle est la méthode la plus stable, la
plus évoluée, la plus ceci ou celà, et je suis complétement perdu là-dedans.
Je précise que je ne cherche pas (pour l'instant en tout cas) un truc
spécifique à telle ou telle distrib, ou comment basculer vers tel ou tel
système (ma machine marche très bien pour l'instant). Je voudrais juste,
par curiosité générale, essayer de comprendre qu'est-ce qui se cache
derrière tout ça.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Rémi Moyen
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Merci ! C'est axé uniquement sur udev, mais en suivant les divers liens (en particulier le premier vers kernel.org), j'arrive à avoir une idée un peu plus claire de la situation globale.
Ceci dit, je ne comprends pas à la lecture de ces pages pourquoi il y a encore tant de bruit autour de devfs ? Est-ce uniquement parce que c'était la seule méthode en 2.4 (si j'ai bien suivi, udev dépend de sysfs qui n'existe que en 2.6) et que beaucoup de machines y sont encore ? Ou est-ce qu'il y a d'autres avantages que ces pages (toutes à la gloire de udev ;-) ) ne mentionnent pas ? -- Rémi Moyen
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me
faire un petit discours en direct :-) ) qui explique de manière
compréhensible et relativement détaillée comment fonctionnent les
différentes manières de gerer /dev ?
Merci !
C'est axé uniquement sur udev, mais en suivant les divers liens (en
particulier le premier vers kernel.org), j'arrive à avoir une idée un
peu plus claire de la situation globale.
Ceci dit, je ne comprends pas à la lecture de ces pages pourquoi il y a
encore tant de bruit autour de devfs ? Est-ce uniquement parce que
c'était la seule méthode en 2.4 (si j'ai bien suivi, udev dépend de
sysfs qui n'existe que en 2.6) et que beaucoup de machines y sont encore
? Ou est-ce qu'il y a d'autres avantages que ces pages (toutes à la
gloire de udev ;-) ) ne mentionnent pas ?
--
Rémi Moyen
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Merci ! C'est axé uniquement sur udev, mais en suivant les divers liens (en particulier le premier vers kernel.org), j'arrive à avoir une idée un peu plus claire de la situation globale.
Ceci dit, je ne comprends pas à la lecture de ces pages pourquoi il y a encore tant de bruit autour de devfs ? Est-ce uniquement parce que c'était la seule méthode en 2.4 (si j'ai bien suivi, udev dépend de sysfs qui n'existe que en 2.6) et que beaucoup de machines y sont encore ? Ou est-ce qu'il y a d'autres avantages que ces pages (toutes à la gloire de udev ;-) ) ne mentionnent pas ? -- Rémi Moyen
myname
Rémi Moyen wrote:
Salut,
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me
faire un petit discours en direct :-) ) qui explique de manière
compréhensible et relativement détaillée comment fonctionnent les
différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page ou plusieurs qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page ou plusieurs qui explique de manière
compréhensible et relativement détaillée comment fonctionnent les
différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page ou plusieurs qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
/dev/ statique : /dev est sur le même filesystem que la racine, vraiment sur disque, et on y crée les entrées nécessaires avec mknod. C'est la méthode historique des Unix, extrêmement robuste, mais elle manque un peu de souplesse au niveau du nommage automatique des périphériques : les périphériques qui apparaissent comme des disques SCSI, comme les clefs USB ou les appareils photos, sont numérotés en fonction de l'ordre de leur détection, et le nom en découle.
devfs : c'est un driver de filesystem particulier, du même genre que /proc/, qu'on monte sur /dev/, et qui fait automatiquement apparaître des entrées correspondant aux périphériques connus par le noyau. Il est en plus capable de stocker des liens symboliques quelconques. Un démon, devfsd, communique avec le noyau par le biais d'une socket, et est notifié quand de nouvelles entrées sont ajoutées (pour faire des liens symboliques), et quand un processus tente d'ouvrir un périphériques qui n'existe pas (pour essayer de le charger). Sur le papier, c'est très bien : ça permet de générer automatiquement des liens symboliques explicites sur les périphériques baladeurs, mais en pratique, l'implémentation était assez buggée, et le mainteneur avait disparu dans la nature. En outre, le chargement automatique des trucs qui n'existent pas était un peu trop coûteux, parce qu'il avait lieu trop souvent pour rien. devfs a été supprimé du noyau il y a peu.
udev : l'idée est de faire la même chose que devfs, mais en userland. La méthode est la suivante : on monte sur /dev/ un tmpfs (un filesystem en mémoire vive ; udev marcherait aussi bien avec n'importe quoi d'autre, mais ce serait une mauvaise idée de le faire travailler sur un vrai disque dur puisque tout est de toutes façons regénéré au boot, et qu'il y a de fortes variations), et un démon userland scanne /sys à la recherche d'information sur les périphériques présents, et crée les entrées correspondantes. Il a les mêmes possibilités que devfs pour ce qui est de nommer des périphériques automatiquement, mais pas la possibilité de charger automatiquement les modules au besoin (mais on peut ruser) : cette dernière posibilité est considérée comme de moindre importance avec les machines actuelles. Du point de vue du noyau, /dev/ redevient un filesystem tout à fait normal, ce qui simplifie la gestion.
Rémi Moyen
wrote in message <43c15716$0$3966$626a14ce@news.free.fr>:
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me
faire un petit discours en direct :-) ) qui explique de manière
compréhensible et relativement détaillée comment fonctionnent les
différentes manières de gerer /dev ?
/dev/ statique : /dev est sur le même filesystem que la racine, vraiment sur
disque, et on y crée les entrées nécessaires avec mknod. C'est la méthode
historique des Unix, extrêmement robuste, mais elle manque un peu de
souplesse au niveau du nommage automatique des périphériques : les
périphériques qui apparaissent comme des disques SCSI, comme les clefs USB
ou les appareils photos, sont numérotés en fonction de l'ordre de leur
détection, et le nom en découle.
devfs : c'est un driver de filesystem particulier, du même genre que /proc/,
qu'on monte sur /dev/, et qui fait automatiquement apparaître des entrées
correspondant aux périphériques connus par le noyau. Il est en plus capable
de stocker des liens symboliques quelconques. Un démon, devfsd, communique
avec le noyau par le biais d'une socket, et est notifié quand de nouvelles
entrées sont ajoutées (pour faire des liens symboliques), et quand un
processus tente d'ouvrir un périphériques qui n'existe pas (pour essayer de
le charger). Sur le papier, c'est très bien : ça permet de générer
automatiquement des liens symboliques explicites sur les périphériques
baladeurs, mais en pratique, l'implémentation était assez buggée, et le
mainteneur avait disparu dans la nature. En outre, le chargement automatique
des trucs qui n'existent pas était un peu trop coûteux, parce qu'il avait
lieu trop souvent pour rien. devfs a été supprimé du noyau il y a peu.
udev : l'idée est de faire la même chose que devfs, mais en userland. La
méthode est la suivante : on monte sur /dev/ un tmpfs (un filesystem en
mémoire vive ; udev marcherait aussi bien avec n'importe quoi d'autre, mais
ce serait une mauvaise idée de le faire travailler sur un vrai disque dur
puisque tout est de toutes façons regénéré au boot, et qu'il y a de fortes
variations), et un démon userland scanne /sys à la recherche d'information
sur les périphériques présents, et crée les entrées correspondantes. Il a
les mêmes possibilités que devfs pour ce qui est de nommer des périphériques
automatiquement, mais pas la possibilité de charger automatiquement les
modules au besoin (mais on peut ruser) : cette dernière posibilité est
considérée comme de moindre importance avec les machines actuelles. Du point
de vue du noyau, /dev/ redevient un filesystem tout à fait normal, ce qui
simplifie la gestion.
Est-ce que quelqu'un pourrait m'indiquer une page (ou plusieurs, ou me faire un petit discours en direct :-) ) qui explique de manière compréhensible et relativement détaillée comment fonctionnent les différentes manières de gerer /dev ?
/dev/ statique : /dev est sur le même filesystem que la racine, vraiment sur disque, et on y crée les entrées nécessaires avec mknod. C'est la méthode historique des Unix, extrêmement robuste, mais elle manque un peu de souplesse au niveau du nommage automatique des périphériques : les périphériques qui apparaissent comme des disques SCSI, comme les clefs USB ou les appareils photos, sont numérotés en fonction de l'ordre de leur détection, et le nom en découle.
devfs : c'est un driver de filesystem particulier, du même genre que /proc/, qu'on monte sur /dev/, et qui fait automatiquement apparaître des entrées correspondant aux périphériques connus par le noyau. Il est en plus capable de stocker des liens symboliques quelconques. Un démon, devfsd, communique avec le noyau par le biais d'une socket, et est notifié quand de nouvelles entrées sont ajoutées (pour faire des liens symboliques), et quand un processus tente d'ouvrir un périphériques qui n'existe pas (pour essayer de le charger). Sur le papier, c'est très bien : ça permet de générer automatiquement des liens symboliques explicites sur les périphériques baladeurs, mais en pratique, l'implémentation était assez buggée, et le mainteneur avait disparu dans la nature. En outre, le chargement automatique des trucs qui n'existent pas était un peu trop coûteux, parce qu'il avait lieu trop souvent pour rien. devfs a été supprimé du noyau il y a peu.
udev : l'idée est de faire la même chose que devfs, mais en userland. La méthode est la suivante : on monte sur /dev/ un tmpfs (un filesystem en mémoire vive ; udev marcherait aussi bien avec n'importe quoi d'autre, mais ce serait une mauvaise idée de le faire travailler sur un vrai disque dur puisque tout est de toutes façons regénéré au boot, et qu'il y a de fortes variations), et un démon userland scanne /sys à la recherche d'information sur les périphériques présents, et crée les entrées correspondantes. Il a les mêmes possibilités que devfs pour ce qui est de nommer des périphériques automatiquement, mais pas la possibilité de charger automatiquement les modules au besoin (mais on peut ruser) : cette dernière posibilité est considérée comme de moindre importance avec les machines actuelles. Du point de vue du noyau, /dev/ redevient un filesystem tout à fait normal, ce qui simplifie la gestion.
