Pas la peine de prendre les autres pour des abrutis.
En plus, le monsieur là-haut, il a raison.
Développons :
udev gère la création des devices à chaud comme il faut, oui. Pour peu qu'il soit configurer, et seulement avec l'aide de hotplug (ou murasaki, c'est ce que j'utilise).
Ce qui est bien, certes, c'est que l'on peut mettre les devices où l'on veut, et dans le filesystem que l'on veut. Perso, j'utilise tmpfs, et toujours /udev (parce que ça marche pas encore bien), mais chacun fait comme il veut.
Certes, ça prend pas plus de place qu'un /dev sans devfs.
Mais oui, c'est lent. Pour peupler le /udev, il met plusieurs secondes sur mon bi-pro. Le procédé consiste à lancer un process udev par device à créer (arggg), et ceci est fait par le script. C'est extrêmement lent par rapport à devfs.
Et en plus, c'est pas foutu de créer tous les devices. Votre système fonctionne bien ? C'est que vous ne devez pas utiliser lvm alors. Pour LVM, c'est une catastrophe : udev ignore tout simplement les devices dm. Le résultat, c'est qu'il est plus compliqué de tester un système avec LVM et udev sans se jeter à l'eau en mettant /udev sur /dev (j'ai commencé à tester avec un chroot, mais bon ...). Et je ne parle même pas du besoin d'avoir un /dev minimal au boot, qui n'était pas nécessaire avec devfs.
Enfin, bon, udev, c'est quand même vachement mieux. C'est juste que sauter le pas devfs -> udev pour les gens comme moi qui font leur propre distrib Linux et qui font leurs propres Live CD, c'est un cap assez irritant à passer.
Y a des CDRW qui vont s'user ...
[^] # Re: Udev atteint la maturité
Posté par ookaze . En réponse à la dépêche Udev atteint la maturité. Évalué à 6.
En plus, le monsieur là-haut, il a raison.
Développons :
udev gère la création des devices à chaud comme il faut, oui. Pour peu qu'il soit configurer, et seulement avec l'aide de hotplug (ou murasaki, c'est ce que j'utilise).
Ce qui est bien, certes, c'est que l'on peut mettre les devices où l'on veut, et dans le filesystem que l'on veut. Perso, j'utilise tmpfs, et toujours /udev (parce que ça marche pas encore bien), mais chacun fait comme il veut.
Certes, ça prend pas plus de place qu'un /dev sans devfs.
Mais oui, c'est lent. Pour peupler le /udev, il met plusieurs secondes sur mon bi-pro. Le procédé consiste à lancer un process udev par device à créer (arggg), et ceci est fait par le script. C'est extrêmement lent par rapport à devfs.
Et en plus, c'est pas foutu de créer tous les devices. Votre système fonctionne bien ? C'est que vous ne devez pas utiliser lvm alors. Pour LVM, c'est une catastrophe : udev ignore tout simplement les devices dm. Le résultat, c'est qu'il est plus compliqué de tester un système avec LVM et udev sans se jeter à l'eau en mettant /udev sur /dev (j'ai commencé à tester avec un chroot, mais bon ...). Et je ne parle même pas du besoin d'avoir un /dev minimal au boot, qui n'était pas nécessaire avec devfs.
Enfin, bon, udev, c'est quand même vachement mieux. C'est juste que sauter le pas devfs -> udev pour les gens comme moi qui font leur propre distrib Linux et qui font leurs propres Live CD, c'est un cap assez irritant à passer.
Y a des CDRW qui vont s'user ...