jeudi 02 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

: Udev atteint la maturité

Posté par tgl (). Modéré le 03 mars 2004.
0
Udev est un système de peuplement dynamique du répertoire /dev, implémenté entièrement dans l'espace utilisateur, visant à remplacer devfs. Il offre une grande souplesse quant au nommage des périphériques, tout en garantissant son déterminisme (c'est-à-dire par exemple qu'il permet de donner un nom précis à chacune de vos clefs USB, quel que soit l'ordre ou le port dans lequel vous les branchez).

Greg Khroah-Hartman a annoncé aujourd'hui la sortie de la version 021, qu'il décrit comme mature : « The TODO is pretty much empty. » Pour ceux qui n'auraient pas encore essayé la chose, c'est le moment.

> Lire les commentaires (88 commentaires, moyenne: 2,1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: Udev atteint la maturité

Posté par Christophe Merlet (page perso, ) le 03/03/2004 à 10:55. (lien). Évalué à 2.

Greg Khroah-Hartman a beau dire tout ce qu'il veut, je préfère devfs, ça marche 100 fois mieux. En tout cas pour moi.

udev est à mon avis a 100 000 lieues d'être mature :((

Le seule manque à devfs est de ne pas savoir gérer la "persistence" des périphériques amovibes, c'est à dire que si vous branchez/débranchez à plusieurs reprises clé USB, appareil photo, zip, etc. les périph passe leur temps à changer de device et c'est pas facile de faire un mount /mnt/{camera,disk,zip} dans le fstab qui marche à coup sûr :((

udev est censé le gérer, mais a coté de ça, il gére les device directement dans le système de fichier racine, ça prend de la place, c'est lent et c'est même pas foutu de créer TOUT les devices nécessaire à la différence de devfs.

Maturité de devfs

Posté par Baptiste Mille-Mathias (page perso, ) le 03/03/2004 à 11:07. (lien). Évalué à 1.

j'entends souvent des gens dire que devfs n'est pas assez bien et qu'il preferent rester a devpts (souvent sous debian d'ailleurs), je n'ai jamais compris pourquoi.
Ayant testé devfs sous gentoo (avant de passer a debian) je trouve ce systeme vraiment plus souple et plus simple que devpts.
Je voudrais bien savoir sur quoi se basent ces personnes pour justifier leur decision.

devfs est déclaré obsolète dans le kernel 2.6.

Posté par petit_bibi () le 03/03/2004 à 11:31. (lien). Évalué à 4.

Il est peut-être important de signaler que dans le kernel 2.6, devfs est consideré comme étant obsolète.

make menuconfig:

Note that devfs has been obsoleted by udev,
<http://www.kernel.org/pub/linux/utils/kernel/hotplug/>.(...)
It has been stripped down to a bare minimum and is only provided for
legacy installations that use its naming scheme which is
unfortunately different from the names normal Linux installations
use.

Comment ça se passe avec chroot?

Posté par Richard Van Den Boom () le 03/03/2004 à 12:05. (lien). Évalué à 1.

Imaginons que je démarre ma machine sur CD-Rom, que je monte une partition de disque dur qui était préalablement sous udev.
Je fais un chroot, genre pour réecrire LILO. Comment ça se passe?

Oui, je sais, c'est le même problème avec devfs.

Richard.

Re: Udev atteint la maturité

Posté par Jllc () le 03/03/2004 à 14:37. (lien). Évalué à 1.

Tiens ça me fait penser à un problème que je rencontre avec devfs et mon lecteur Zip sur port parllèle.

Avec l'anicien système, il me suffisait de brancher le lecteur et d'essayer de monter la disquette zip pour que le module noyau soit charger, car il y avait une association tel n° de major tel module.

Avec devfs, c'est quand le module se charge qu'il signal quel périphérique il gère, et que l'entrée est crée dans /dev . Donc je dois moi même charger le module pour utiliser mon lecteur ZIp.

Tous ça parce que contrairement au PCMCIA ou à l'USB, le port parallèle est incapable de signaler le branchement d'un périphérique.


Est-ce que le problème se poserait toujours avec ce Udev ?

Re: Udev atteint la maturité

Posté par tgl () le 03/03/2004 à 18:41. (lien). Évalué à 2.

Qlqs autres bookmarks +/- issus du monde Gentoo mais qui peuvent être interressants aussi pour des gens d'autres horizons (enfin, les deux premiers au moins) :
http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html(...)
http://www.reactivated.net/udevrules.php(...)
http://www.gentoo.org/doc/en/udev-guide.xml(...)

Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....

Posté par Olivier LAHAYE (page perso, ) le 03/03/2004 à 22:49. (lien). Évalué à 5.

A mon avis, la notion de filesystem virtuel est bien meilleur que des bidouilles de créations de liens par des mécanismes plus ou moins alambiqués. En effet, que se passera t'il si on bouge entre 2 versions de kernel avec des changements dans les devices? on chage udev et le config file à chaque boot? on utilise /etc/alternatives?....

Tout ça pour quoi? la persistance des devices!!!

Il faudrait peut être regarder comment ça se passe ailleurs!!!

Par example, sur Digital unix, il y a un système basé sur une minibase de donnée. dès qu'un nouveau device est détecté, le devfs équivalent recherche l'identité de ce périphérique dans cette minibase. S'il est trouvé (ex: un disque SCSI avec un serial number de 2423SSS-UX auquel est assigné le device /dev/hde) on met l'inode hde dans le /dev virtuel. Si ce périphérique n'est pas trouvé dans la base, on mémorise son identité et on lui donne un device libre (example: /dev/hdf).

Ainsi: pas de fichiers de conf à éditer pour dire: le disque avec numéro de série a le device /dev/hdf. (l'identification peut se faire par serial number, calcul sur des caractèristiques, labels...)

Biensur en cas de disque mort, on peut avec une simple commande librérer le device.

C'est comme windows: pour un device, on peut assigner un lettre ou laisser le système choisir.(sauf que c'est mal foutu, car la persistance n'existe que si le device est présent à tous les boot (ce qui n'est pas très persistant. Mais au moins, hdb peut être le premier disque et hda le second)

Avec un device filesystem: pas de problèmes de /dev avec des déchets qui restent après un reboot malheureux.
avec une base (par example un .db), la persistance est assurée.

Aujourd'huis, hotplug, /etc/modules /etc/modules.conf sont des uzines à gaz qui atteingent leur limites.

En effet, rien n'est unifié. certains modules sont charcés par des scripts rc.*, d'autres par pcmcia, d'autres par hotplug, et quand rien ne se déclanche on utilise /etc/modules, berf, c'est le souk.

En ajoutant udevfs, ce sera encore pire, car on va rajouter des crottes dans /dev et je ne sais pas comment on va faire le ménage.

=> Un example ou une base de donnée serait bien plus utile que udevfs:
On branche un camescope, hotplug charge: ohci1394,ieee1394,dv1394.
Normal, sauf que pour faire un dvgrab il faut aussi raw1394.
Donc si on fait modprobe raw1394 et qu'on l'utilise avec le camescope connecté, pour quoi ne pas rajouter un mécanisme qui se souvient que pour ce périphérique, on voulait aussi raw1394 (hope dans la base).

Après, avec un outil on pourrait très bien pour chaque périphérique montrer les modules déclanchés et donner l'option de déasactiver les modules optionnels (tels que raw1394 pour un camescope).

Ou a contrario, on pourrait faire un mécanisme dans devfs qui réagit en fonction des appels stat ou open. Tiens? on a fait un stat sur /dev/raw1394, c'est le devicename du module raw1394, alors je le charge.

Désolé pour ce message un peu long.... y'a encore des lecteurs?... mais je pense que si les développeurs regardaient en dehors de linux/unix avant de se lancer dans un trucs, ça serait pas un mal.

Olivier.

Commentaire inutile...

Posté par Carbon Kid () le 12/05/2004 à 11:56. (lien). Évalué à 1.

C'est juste pour forcer templeet à recréer la page, pour pouvoir naviguer avec la toolbar.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2944s (dont 0.0546 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !