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.
# Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....
Posté par Olivier LAHAYE . En réponse à la dépêche Udev atteint la maturité. Évalué à 5.
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.