> 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?
Je ne comprends sincèrement pas à quel problème tu pense. Est-ce que tu peux concrétiser, même avec un exemple bidon stp ?
> 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).
C'est pas une mauvaise, rien ne t'empêche d'implémenter cette politique de nommage dans un petit script appelé par une règle udev. C'est tout l'intérêt d'avoir déporté cette gestion des noms en userspace : ça ouvre plein de possibilités. Le fichier de conf par défaut reprenant un nommage standard est un simple exemple, fait pour nous laisser en terrain connu, mais ils y a clairement mieux à faire. Là je crois que c'est maintenant plus aux distributions de faire leur boulot pour rendre les choses plus conviviales, elles en ont enfin la possibilité.
Sur ce topic de rendre les choses conviviales, cf aussi ce qui se prépare du côté de freedesktop autour de hotplug/udev/dbus. Par exemple les slides de Robert Love au dernier Fosdem : http://tech9.net/rml/talks/rml_fosdem_2004.sxi(...)
> 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.
J'ai actuellement 140 noeuds dans mon /dev, dont 64 pour les consoles virtuelles. C'est largement moins que ce que j'ai pu voir par le passé, et ça n'est (sauf les fameuses consoles virtuelles, mais bon, je pourrais baisser leur nombre dans le noyau) que des devices utiles. Mais où sont les crottes ? :)
> 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).
S'en "souvenir", moi je suis contre sans hésiter. J'ai aucune envie quand je teste un module de me le trainer après à chaque fois que je reviens dans un contexte similaire et d'avoir à bidouiller pour forcer l'oubli de la chose, merci. Par contre donner la possibilité de le spécifier quelque part, oui, ça parait utile. Ça peut se rajouter facilement à la main dans le handler firewire de hotplug, mais c'est pas très user friendly. Ça peut aussi se rajouter dans un script appelé depuis la règle udev qui match le dit caméscope, c'est sûrement le plus simple, reste à savoir si c'est propre. Y'a sûrement effectivement une méthode plus standard à inventer, mais de toute façon maintenant techniquement l'infrastructure est là pour la mettre en place sans problème. (Ça pourrait aussi être fait par une appli/démon qui gère ça en réagissant à un évenement dbus "caméscope branché".)
[^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 3.
> changements dans les devices? on chage udev et le config file à chaque
> boot?
Je ne comprends sincèrement pas à quel problème tu pense. Est-ce que tu peux concrétiser, même avec un exemple bidon stp ?
> 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).
C'est pas une mauvaise, rien ne t'empêche d'implémenter cette politique de nommage dans un petit script appelé par une règle udev. C'est tout l'intérêt d'avoir déporté cette gestion des noms en userspace : ça ouvre plein de possibilités. Le fichier de conf par défaut reprenant un nommage standard est un simple exemple, fait pour nous laisser en terrain connu, mais ils y a clairement mieux à faire. Là je crois que c'est maintenant plus aux distributions de faire leur boulot pour rendre les choses plus conviviales, elles en ont enfin la possibilité.
Sur ce topic de rendre les choses conviviales, cf aussi ce qui se prépare du côté de freedesktop autour de hotplug/udev/dbus. Par exemple les slides de Robert Love au dernier Fosdem : http://tech9.net/rml/talks/rml_fosdem_2004.sxi(...)
> 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.
J'ai actuellement 140 noeuds dans mon /dev, dont 64 pour les consoles virtuelles. C'est largement moins que ce que j'ai pu voir par le passé, et ça n'est (sauf les fameuses consoles virtuelles, mais bon, je pourrais baisser leur nombre dans le noyau) que des devices utiles. Mais où sont les crottes ? :)
> 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).
S'en "souvenir", moi je suis contre sans hésiter. J'ai aucune envie quand je teste un module de me le trainer après à chaque fois que je reviens dans un contexte similaire et d'avoir à bidouiller pour forcer l'oubli de la chose, merci. Par contre donner la possibilité de le spécifier quelque part, oui, ça parait utile. Ça peut se rajouter facilement à la main dans le handler firewire de hotplug, mais c'est pas très user friendly. Ça peut aussi se rajouter dans un script appelé depuis la règle udev qui match le dit caméscope, c'est sûrement le plus simple, reste à savoir si c'est propre. Y'a sûrement effectivement une méthode plus standard à inventer, mais de toute façon maintenant techniquement l'infrastructure est là pour la mettre en place sans problème. (Ça pourrait aussi être fait par une appli/démon qui gère ça en réagissant à un évenement dbus "caméscope branché".)