Udev atteint la maturité

Posté par  . Modéré par Nÿco.
Étiquettes :
0
3
mar.
2004
Linux
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.

Aller plus loin

  • # Re: Udev atteint la maturité

    Posté par  (site Web personnel) . É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.
    • [^] # Re: Udev atteint la maturité

      Posté par  . Évalué à -1.

      tu veux dire TOUS :)
    • [^] # Re: Udev atteint la maturité

      Posté par  . Évalué à 0.

      t'as essayé quelle version? pas celle-ci j'imagine, ces problèmes sont peut-être réglés.
      pour moi, devfs est franchement une daube, j'attend qu'une chose c'est que udev marche bien.
      • [^] # Re: Udev atteint la maturité

        Posté par  . Évalué à 1.

        devfs est franchement une daube

        tu peux developper ?
        • [^] # Re: Udev atteint la maturité

          Posté par  . Évalué à 3.

        • [^] # Re: Udev atteint la maturité

          Posté par  . Évalué à 9.

          > devfs est franchement une daube

          Un point parmi d'autres (cité dans le document devfs vs udev) est qu'il est gavé de race conditions insolubles et de deadlocks.

          De plus, l'API de devfs est non adaptée. Certaines fonctions sont inutilisées, les structures sont lourdingues, etc.

          Puis bon, faut avouer que devfs a pas particulièrement réussi sa percée donc il n'a peut être jamais reçu le soin nécessaire à sa réalisation. Lors du développement 2.3, il était nécessaire d'avoir une allocation dynamique des entrées dans /dev, quelqu'un a proposé devfs, il a été pris. Donc rien de très réfléchi, etc.

          udev, au contraire, a essayé dès le début d'être clean, léger et orienté userland (/sbin/hotplug est utilisé par udev).

          Udev réussira t'il là où devfs a échoué ? wait & see.
        • [^] # Ne lui répondez pas!

          Posté par  . Évalué à 0.

          Vous voyez bien que c'est un appeau à trolls à peine déguisé..
        • [^] # Re: Udev atteint la maturité

          Posté par  . Évalué à -1.

          > devfs est franchement une daube

          Un point parmi d'autres (cité dans le document devfs vs udev) est qu'il est gavé de race conditions insolubles et de deadlocks.

          De plus, l'API de devfs est non adaptée. Certaines fonctions sont inutilisées, les structures sont lourdingues, etc.

          Puis bon, faut avouer que devfs a pas particulièrement réussi sa percée donc il n'a peut être jamais reçu le soin nécessaire à sa réalisation. Lors du développement 2.3, il était nécessaire d'avoir une allocation dynamique des entrées dans /dev, quelqu'un a proposé devfs, il a été pris. Donc rien de très réfléchi, etc.

          udev, au contraire, a essayé dès le début d'être clean, léger et orienté userland (/sbin/hotplug est utilisé par udev).

          Udev réussira t'il là où devfs a échoué ? wait & see.
    • [^] # Re: Udev atteint la maturité

      Posté par  . Évalué à 10.

      > udev est censé le gérer
      Pourquoi "censé" ? Il le gère tout court, d'où nous vient ce bémol ?

      > il gére les device directement dans le système de fichier racine
      Il gère les devices où tu veux. Perso je les mets dans un répertoire /dev où est monté un ramfs.

      > ça prend de la place
      Gné ?

      > c'est lent
      C'est lent à faire quoi ? Tu as des chiffres ?

      > même pas foutu de créer TOUT les devices nécessaire
      Mince, moi qui croyait que mon système fonctionnait très bien, en fait je dois rêver.

      Enfin bref, tout ça pour dire que j'ai bien du mal à trouver tes "100 000 lieues", et que je ne vois là qu'un gros troll fudesque. Ce serait pas mal de développer un peu là si tu as vraiment des arguments à nous faire partager.
      • [^] # Re: Udev atteint la maturité

        Posté par  . Évalué à 5.

        Il gère les devices où tu veux. Perso je les mets dans un répertoire /dev où est monté un ramfs.

        Question de goût je préfère tmpfs, ça ne prend que la place nécessaire et pas plus... voire /usr/src/linux/Documentation/filesystems/tmpfs.txt
      • [^] # Re: Udev atteint la maturité

        Posté par  . Évalué à 6.

        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  . Évalué à 8.

          Pas la peine de prendre les autres pour des abrutis.
          Ça n'est pas la peine de me prêter des intentions que je n'ai pas. Le monsieur là-haut, il a l'air d'avoir une grosse dent contre udev, je n'ai jamais pensé que ça faisait de lui un abruti pour autant. Mais il aligne plusieures critiques majeures d'udev sans la moindre argumentation, c'est un post d'humeur, c'est pas grave on en fait tous parfois, mais c'est effectivement pas ceux qui attirent les réponses les plus sympathiques. En l'occurence, je me trouvais plutôt modéré sur ce coup là, fait chier, faut croire que c'est pas encore ça.

          Pour le support de LVM, j'ai essayé un peu (enfin LVM2), et j'avais eu à créer le /dev/mapper/control à la main. Je dis pas que 100% des devices peuvent être créés par udev. Déjà, y'en a qui n'exportent rien dans /sys/ (genre les drivers nvidia sans le bon patch), donc là c'est mal barré, y'en a aussi dont on peut avoir besoin avant même d'avoir lancé udev (genre /dev/null), etc. Mais simplement, ça n'enlève rien à udev, et ça n'empêche absolument pas de l'utiliser de façon pleinement fonctionnelle comme remplacement de devfs. Par contre, c'est clair que ça demande un peu plus de travail sur les scripts d'init que devfs, donc si vous êtes justement là dedans, effectivement, ça peut apparaître comme une certaine régression sur le coup.

          Pour ce qui est de la boucle de population du /dev/, bah... c'est quoi le problème de faire une boucle d'appel d'un aussi petit programme ? On fait ça tous les jours dans n'importe quel script shell, non ? Ici sur un portable 1,3 GHz la boucle s'execute en 0,28 secondes pour 112 itérations. Que ça puisse monter à qlqs secondes chez vous, ça me parait beaucoup, mais c'est effectivement pas impossible. Ceci dit, on s'en fout un peu, ça n'arrive qu'au boot, enfin bon, je trouve pas que l'argument pèse bien lourd. C'est pour ça que je voulais m'assurer que c'était bien là la lenteur désignée (parceque dans plusieurs trolls on peut lire en gros "udev c'est user-space donc ça va ramer d'accéder au devices", ce qui est bien sûr totalement absurde).

          Bon courage pour passer le cap irritant.
  • # Maturité de devfs

    Posté par  . É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.
    • [^] # Re: Maturité de devfs

      Posté par  . Évalué à 2.

      La peur du changement ?
      • [^] # Re: Maturité de devfs

        Posté par  . Évalué à 1.

        Ca peut etre un début de reponse :)
        mais j'attends de personnes qui utilisent un GNU/linux une analyse un peu plus poussée :D.
    • [^] # Re: Maturité de devfs

      Posté par  . Évalué à 5.

      les défauts de devfs (surtout la non-persistance du nommage des périphériques) font qu'il est quasiment inutilisable pour bcp de monde.
      Il suffit d'avoir un lecteur de cartes (memory stick + compactflash + ... avec un device par type de carte), un PDA par lequel on monte sa carte méroire par usb, pareil avec un appareil photo, etc... tous ces devices vont se nommer /dev/sdx. Le grand jeu après c'est d'essayer de deviner quel device correspond à quel périphérique.
      Si on a une souris + une tablette graphique USB, pareil.

      Honnêtement, vaut mieux pas essayer d'utiliser devfs dans ces conditions. devfs a été mal pensé dès le départ en ce qui concerne tout ce qui est débranchable à chaud.
      • [^] # Re: Maturité de devfs

        Posté par  (site Web personnel) . Évalué à 2.

        Ce dont tu parles tu le vois aussi sans devfs donc je vois pas le rapport avec la question.
        • [^] # Re: Maturité de devfs

          Posté par  . Évalué à 1.

          Oui, persone n'a reellement repondu a la question :[
          • [^] # Re: Maturité de devfs

            Posté par  (site Web personnel) . Évalué à 1.

            ben, chose qui me gonfle dans devfs (et je suis pas le seul), c le nommage a rallonge.

            /dev/disc/truc/chose/coin/gruik0

            le genre de truc qui m'ennerve.

            Tu fais un df -h et tout est décalé...

            de plus, vu que les liens n'on jamais disparus, j'ai pas trop vu l'interet :)

            D'ailleurs, dans udev, on revient a l'ancienne notation qui est quand meme plus claire.

            Apres, sur ma cooker, je vois vraiment pas en koi udev est lent!(reponse au premier poste)
            • [^] # Re: Maturité de devfs

              Posté par  (site Web personnel) . Évalué à 1.

              Je confirme sur Ma mandrake 10.0 cooker c'est pas lent du tout...

              le lancement de hotplug prend dans les 5-7 secondes en tout sur une MSI KT4AV-L, radeon 9000pro, AthlonXP-2100+...
              avec carte réseau interne+3com+sourie usb+sblive+carte son interne+bttv...

              Je trouve pas que sa change grand chose pour moi...
              Je n'ai pas fait la différence, et je savais même pas a quoi sa correspondais jusqu'a présent...

              Franchment c'est parce que t'a du mal compiler/configurer ton truc...

              Perso le boulo de mandrake est parfois bien meilleur que d'autre distrib en ce qui est de l'integration de certaines choses très récentes...

              Je ne dis pas que c'est la milleur distribution, mais je fais tout pour que elle le soit...

              Un conseil : pompe les conf de mandrake, elle marche bien, pas au petit oignons, mais sa marche...
              • [^] # Re: Maturité de devfs

                Posté par  . Évalué à 1.

                Pas lent du tout 5 à 7 secondes de plus sur un boot!?

                On doit pas tout à fait vivre sur la même planète...
                • [^] # Re: Maturité de devfs

                  Posté par  (site Web personnel) . Évalué à 1.


                  Pas lent du tout 5 à 7 secondes de plus sur un boot!?

                  On doit pas tout à fait vivre sur la même planète...


                  C'est sûr que si tu rebootes tous les jours...

                  Il y a aussi des gens qui rebootent seulement une fois par mois voire moins, alors ne penses pas que parce que toi 1 boot plus long de 5 à 7 sec te gênent que c'est le cas pour tous.
      • [^] # Re: Maturité de devfs

        Posté par  . Évalué à 5.

        Voilà, je suis dans ce cas là : j'ai une souris et une tablette. Pour être sur de ne pas avoir de souci, j'ai pris l'habitude de toujours brancher la tablette une fois le système démarré (la souris usb est toujors branchée).

        Et puis, un autre truc est que j'ai plusieurs périphériques mass-storage : un appareil photo, un graveur externe, un disque dur (plusieurs partitions fat32/ext3) et parfois l'archos d'un ami. Avec tout ça, je ne trouvais pas comment faire des entrées qui vont bien dans fstab. Je comprends maintenant que ce n'est pas possible avec devfs :-(

        Je vais jeter un oeil sur udev avec intérêt, en espérant qu'il ne soit pas trop difficile de faire le changement (sans tout casser et avec possibilité de retour à devfs en cas de non-satisfaction) :-)
        • [^] # Re: Maturité de devfs

          Posté par  . Évalué à 3.

          > Je vais jeter un oeil sur udev avec intérêt, en espérant qu'il ne soit pas trop
          > difficile de faire le changement

          Ça dépend fortement de la distrib' utilisée. Par expérience, je peux dire que ça se fait très bien sous Gentoo, et par lecture à droite à gauche que ça n'est pas un problème sous Fedora. À part ça, je sais pas, ce serait intérressant que des utilisateurs d'autres distribs se manifestent.
          • [^] # Re: Maturité de devfs

            Posté par  . Évalué à 3.

            J'utilise udev pour gérer mon /dev, par défaut c'est dans /udev que les périfs sont créé, alors y'a une petite bidouille, je mounte un tmpfs sur /dev avant.

            Perso j'ai rajouté un petit truc dans le script d'udev:
            /sbin/mknod ${udev_root}/null c 1 3
            /sbin/mknod ${udev_root}/console c 5 1

            Faut bien faire attention à ce que le script /etc/init.d/devpts s'execute _après_ udev qui doit s'executer après mountall.sh.

            Sous Debian S{arge,id}.
            • [^] # Re: Maturité de devfs

              Posté par  . Évalué à 2.

              Je suis sous Debian sarge et je n'ai pas trouvé de paquet debian qui fournit udev. As-tu des infos dessus ou as tu toi même compilé celui-ci ?

              Sinon, j'aimerais savoir pourquoi udev n'utilises pas /dev directement au lieu de /udev? Et a t'on besoin de devpts avec udev et pourquoi ?
              Enfin bref des questions que la doc d'udev n'a pas réussi à complétement répondre et de façon claire.
              • [^] # Re: Maturité de devfs

                Posté par  . Évalué à 3.

                > Je suis sous Debian sarge et je n'ai pas trouvé de paquet debian qui fournit udev. As-tu des infos dessus ou as tu toi même compilé celui-ci ?

                il arrive :-)
                http://incoming.debian.org/(...)
                • [^] # Re: Maturité de devfs

                  Posté par  . Évalué à 3.

                  Attention car ce package remplace /dev par un ramdisk et comme udev ne permet pas (encore) de creer tout les devices, l'effet probable est de rendre votre systeme inutilisable ou du moins difficilement utilisable.

                  Rien de grave cependant car le /dev original est toujour present (sous le ramdisk).

                  Avant de demarer udev (/etc/init.d/udev start), je recommande donc d'editer le fichier /etc/udev/udev.conf pour remplacer les lignes

                  udev_root="/dev/"
                  udev_db="/dev/.udev.tdb"

                  par

                  udev_root="/udev/"
                  udev_db="/udev/.udev.tdb"

                  Cela vous permettra d'experimenter dans /udev sans perturber votre /dev.
            • [^] # Re: Maturité de devfs

              Posté par  . Évalué à 1.

              >Faut bien faire attention à ce que le script /etc/init.d/devpts >s'execute _après_ udev qui doit s'executer après mountall.sh.

              c'est pas clair pour moi, tu dis que udev doit s'executer apres mountall.sh ????
              Parceque dans le paquet experimental qui apparait aujourd'hui , udev se charge en premier et justement il semble y avoir un probleme ....
      • [^] # Re: Maturité de devfs

        Posté par  . Évalué à 1.

        >> devfs a été mal pensé dès le départ en ce qui concerne tout ce qui est débranchable à chaud.

        Ce qui est un combe, car c'est pour moi l'une de ses principales utilité : voir apparaitre le device dés que je connecte ma clef usb. Mais c'est vrai qu'il te met un sacré souk dans les /dev/sdx. Comment udev fonctionne-t-il par rapport à devfs avec ce genre de périphériques d'ailleurs ?
        • [^] # Re: Maturité de devfs

          Posté par  (site Web personnel) . Évalué à 4.

          Sur une fedora (donc sans devfs), pour gérer plusieurs clefs USB différentes mais une seule est connectée à un instant donné, j'utilise le script présenté la :

          https://listman.redhat.com/archives/rhl-devel-list/2003-August/msg00(...)

          Toute clef USB est maintenant 'mountable' par un utilisateur via le répertoire /mnt/diskonkey (ajustable suivant ses volontes).

          ++, Htam.
        • [^] # Re: Maturité de devfs

          Posté par  . Évalué à 5.

          Quand tu branches ce type de périph, hotplug réveille udev pour que ce dernier crée le/les nodes et symlinks dans ton répertoire des périphériques. Après, ce que fait udev dépend de ta config. Tu peux te contenter d'une config par défaut immitant le nommage de feu devfs (-> "/dev/sdX" + des trucs dans "/dev/scsi/..." + des trucs dans "/dev/usb/..."), ou bien spécifier des règles plus particulière, par exemple en fonction des numéros de série de tes clefs usb, et avoir donc un node "sesame" pour l'une et "deschamps" pour une autre. Bref, tu gères un peu comme tu veux. Tu spécifies aussi tes permissions bien sûr. Y'a qlqs exemples assez représentatifs dans le fichier de conf par défaut, qui montrent la souplesse de la chose. Faut bien voir que udev peut appeler des scripts externes au sein des règles, donc y'a moyen de faire des trucs vraiment rigolos (je me souviens d'avoir vu passer sur la lkml un script utilisant freedb pour créer un nom de dvice device /dev/artiste/album quand tu inserais un cd audio...).
      • [^] # Re: Maturité de devfs

        Posté par  . Évalué à 1.

        pour tout ce qui est USB, j'utilise devlabel, qui te cree un link dans /dev suivant le device connecté (et duement configuré)
    • [^] # Re: Maturité de devfs

      Posté par  (site Web personnel) . Évalué à 3.

      devpts ça n'a rien à voir, c'est juste les pseudo-terminaux (tapes tty dans un xterm et en console).
  • # devfs est déclaré obsolète dans le kernel 2.6.

    Posté par  . É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  . É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: Comment ça se passe avec chroot?

      Posté par  . Évalué à 1.

      troll déguisé lilo/grub ?
      C'est plutôt un problème de lilo à mon sens...
    • [^] # Re: Comment ça se passe avec chroot?

      Posté par  . Évalué à 1.

      Tu pourrais préciser ton problème. C'est le genre de manip qui marche chez moi avec devfs.
    • [^] # Re: Comment ça se passe avec chroot?

      Posté par  . Évalué à 1.

      Je ne vois pas trop le problème ici.

      Tu t'inquiètes de savoir si tu seras capable d'avoir les devices pour accéder à /dev/ide/.../disc (par exemple) c'est bien ça ?

      Ben si oui, tous les livecd que j'ai rencontré jusqu'ici (pas beaucoup mais bon) avaient un /dev contenant au moins ça. Donc pas de problème pour que lilo (ou grub ou autre) puisse y écrire.

      Même si tu utilise devfs ou udev sur ton système, lorsque tu es sur un livecd, tu es sur un *autre* système et rien ne t'empêche d'utiliser mknod pour créer tes devices à la main s'ils manquent (au pire).

      Ou alors j'ai loupé quelque chose dans ta question ?
      • [^] # Re: Comment ça se passe avec chroot?

        Posté par  . Évalué à 1.

        Ce que je voulais décrire comme situation, c'est juste une situation de ce type (lilo ou kernel foireux) où tu démarres ta machine sur un CD (Slackware, par exemple), monte ton disque et passes en chroot pour faire quelques manipulations. Si ces dernières nécessitent un accès à des devices, je suppose qu'il est nécessaire qu'un répertoire /dev standard soit présent, non? Où alors comme udev fonctionne en espace utilisateur, est-il possible de le démarrer à ce moment, pour peu que le kernel du CD de boot le supporte?
        Je sais que tu peux créer tes devices à la main, mais c'est une solution un peu... basique.

        Richard
        • [^] # Re: Comment ça se passe avec chroot?

          Posté par  . Évalué à 3.

          Si ces dernières nécessitent un accès à des devices, je suppose qu'il est nécessaire qu'un répertoire /dev standard soit présent, non?

          Tout à fait. Comme déjà dit dans ma première réponse et dans celle d'Hervé Cauwelier, les livecd que j'ai rencontré jusque là en avaient tous un.

          Je sais que tu peux créer tes devices à la main, mais c'est une solution un peu... basique.

          Certes ;-)
          Mais ça a le mérite de marcher très bien. Sinon, j'imagine qu'il doit maintenant trainer des livecd qui utilisent devfs (ou même udev ?) pour remplir leur /dev, non ?

          Ce serait une solution beaucoup moins basique, déjà ;-)
          • [^] # Re: Comment ça se passe avec chroot?

            Posté par  (site Web personnel) . Évalué à 1.

            non, il parlait d'un /dev dans le chroot.
            Je pense que lilo marche tres bien sans mais dans le doute: mount -o bind!
            • [^] # Re: Comment ça se passe avec chroot?

              Posté par  (site Web personnel) . Évalué à 1.

              je prend l'exemple de la mandrake que j'utilise depuis un bail

              pour recup une install de lilo foireuse

              je boot le cd avec le noyau de rescue, je monte mon / dans /mnt
              je chroot /mnt j'édite lilo.conf si nécessaire, et je tappe lilo
              Il me fait deux trois warning comme quoi il trouve pas certain de ses devices
              mais il s'installe parfaitement reboot et tout tourne...

              (pour les trolleur, je n'utilise pas grub donc je critique pas, tout ce que je sais c'est qu'il supporte pas un frambuffer de 1280x1024 avec un super theme 256 couleurs, donc j'utilise lilo)

              et je dois avouer que lilo s'est pas mal amélioré, je n'ai plus depuis la mdk 9.2 de lilo qui s'installent mal et c'est agréable...

              le cd de rescue mandrake a même dépanné un pote qui arrivais plus a remettre lilo (il a pas de grub pour la raison ci-dessus)...

              Enfin voila une méthode qui pourra vous dépanner...

              j'iumagine que tout les cd de rescue doivent le faire, mais comme je connais seulement ceux de mandrake je n me prononcerais que sur ces derniers...
    • [^] # Re: Comment ça se passe avec chroot?

      Posté par  . Évalué à 1.

      udev ou devfs se montent sur le répertoire /dev, qui contenait déjà quelque chose. Les distributions ont un répertoire /dev par défaut dans leur base root.

      Sinon, comme dis, tu créé les devices à la main ou avec le script MAKEDEV.
  • # Re: Udev atteint la maturité

    Posté par  . É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  . Évalué à 2.

      extrait de la faq d'udev donnée en lien:

      Q: But udev will not automatically load a driver if a /dev node is opened
      when it is not present like devfs will do.
      A: If you really require this functionality, then use devfs. It is still
      present in the kernel.

      Q: But wait, I really want udev to automatically load drivers when they
      are not present but the device node is opened. It's the only reason I
      like using devfs. Please make udev do this.
      A: No. udev is for managing /dev, not loading kernel drivers.

      Par conséquent, je pense que le prob persiste.

      Est-ce que le fait de charger automatiquement tous les modules dont en a potentiellement besoin par modules.autoload prend-il bcp de place dans le noyau ?
      • [^] # Re: Udev atteint la maturité

        Posté par  . Évalué à 2.

        Etant donné que :
        - en général, si on met des modules, c'est pas pour tout charger au démarrage
        - dans le 2.6, le déchargement des modules est déconseillé, même si c'est possible

        C'est donc un gros moins pour udev.
        Car effectivement, à quoi ça sert d'avoir des modules dans ce cas ?
        Y a-t-il une solution élégante à ce problème ?
        • [^] # Re: Udev atteint la maturité

          Posté par  . Évalué à 1.

          Une solution, pas élégante du tout, serait de tout mettre en dur.
          Pour les distributions binaires il faudrait placer les bons modules dans modules.autoload en fonction de la config détectée au chargement du noyau. Peut-être que kudzu, discover ou drakconf le font déjà.
          • [^] # Re: Udev atteint la maturité

            Posté par  (site Web personnel) . Évalué à 1.

            mandrake a harddrake qui rajoute les modules en fonctions des périphérique détectés au démarage...

            mais pour certain truc /etc/modprobe.preload et /etc/modules.conf dois vent se faire ajouter quelque lignes...

            typiquement pour via_nomduchipset qui load agpgart
            pour nvidia, ce qui permet de perdre moins de temps lors du lancement de xfree

            Je parle ici d la mandrake 10.0, car la 9.2 est ready kernel 2.6 avec devfs, mais bon faut faire les modifs a la main...
        • [^] # Re: Udev atteint la maturité

          Posté par  . Évalué à 1.

          - en général, si on met des modules, c'est pas pour tout charger au démarrage

          si le matos est pas présent, le module n'occupe (quasiment) aucun espace, à part ses symboles.
          pour le voir, il suffit de faire un lsmod après avoir bouté un noyau de distrib standard. T'auras pas bcp de modules
      • [^] # Re: Udev atteint la maturité

        Posté par  . Évalué à 2.

        Je suis pas un spécialiste, mais si j'ai bien compris udev permet d'appeler toute sorte de scripts, y'a donc sans doute moyen d'ajouter un modprobe mondriver quelque part... (moinssez-moi si j'ai dit une connerie)

        pour ta deuxième question:
        nyarlathotep:/home/sylvain# du -h /lib/modules/2.4.18
        ...
        1,7M /lib/modules/2.4.18

        ça donne déjà une idée.
      • [^] # Re: Udev atteint la maturité

        Posté par  (site Web personnel) . Évalué à 1.

        sans devfs, cela fonctionne aussi:

        j'avais ca dans mon 2.4 pour chargé usb-storage quand je voulais monter ma clef usb:

        alias block-major-8 usb-storage
        above usb-storage sg

        et dans le 2.6 c devenu:

        install usb-storage /sbin/modprobe --first-time --ignore-install usb-storage && { /sbin/modprobe sg; /bin/true; }


        conclusion: c'etait mieux avant! :)
    • [^] # Re: Udev atteint la maturité

      Posté par  . Évalué à 3.

      Tu peux créer le noeud qui va bien à la mimine dans un script d'init par exemple. Ça ne pose pas de pb d'avoir des noeuds qui n'ont pas été générés par udev, et le noyau lui est bien sûr toujours capable de faire du chargement de module au besoin. Bref tu reviens, pour ce périphérique particulier, à la situation d'avant devfs. Là, udev, n'est tout simplement pas concerné en fait.
      Le truc que devfs/devfsd savaient faire et que udev ne fait pas, c'était l'auto-chargement-et-création pour des noeuds qui n'existaient pas encore : tu pouvais avoir une règle pour dire «si on essaye d'accéder à un dénommé /dev/zip, alors charge le module machin, et fait un lien de /dev/zip vers /dev/scsi/truc». (Donc le chargement systématique du module comme tu le décris n'était pas nécéssaire en fait.)
  • # Re: Udev atteint la maturité

    Posté par  . É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  (site Web personnel) . É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.
    • [^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....

      Posté par  (site Web personnel) . Évalué à 1.

      En plus, quand je vois les questions FAQ(4,5,6,) j'allucine!!! on retourne carrément à l'age de pierre...

      En plus ils se contredisent:
      à un moment, il est dit que udev sur le file system prends moins de mémoire, et après, il est dit que le mécanisme de modprobe ne sera pas mis en place, car on charge tous les drivers en RAM....

      Il faudrait savoir si la RAM pose problème ou pas.

      ...
      • [^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....

        Posté par  (site Web personnel) . Évalué à 4.

        "il est dit que le mécanisme de modprobe ne sera pas mis en place, car on charge tous les drivers en RAM...."

        non, il est dit que vu que l'ancien fonctionnement etait de charger un driver en fonction de l'acces au device. Le nouveau est de créer le device si le périphérique est branché. C'est tout l'interet du nouveau procédé:

        avant:

        si j'accede a /dev/sda1 pour monter ma clef usb, alors le drivers usb-storage et sg se charge en mémoire. Mais, si je n'ai pas branché la clef usb, le drivers se charge quand meme alors que y'a rien d'interressant. On ne faisait pas ici de la detection de presence de materiel mais d'utilisation de materiel

        maintenant:

        avec hotplug, c lui qui decide de charger le module en fonction du nouveau materiel branché. Donc, si le module est chargé, c que le périphérique existe. Contrairement au cas précédent.

        Tu comprend bien que le second cas(maintenant) empeche le fonctionnement du premier vu que les devices ne sont crée que lorsque le périphérique existe.
    • [^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....

      Posté par  (site Web personnel) . Évalué à 1.

      "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."

      Le pcmcia, c'est un cas particulier, je sais pas trop, je laisse de coté.

      Par contre, rc.modules est obsolete(depuis un bout de temps). Il n'existe que pour une compatibilité ascendante.

      Par contre, j'espere que le modprobe.conf n'est la que le temps de la migration et qu'apres, seul hotplug sera maitre du chargement des modules. En clair, qu'il soit capable de tout détecter(reseau, video, son, tv, ...). Je ne dis pas que le modprobe.conf doit disparaitre mais que le systeme doit fonctionner soit avec le couple udev/hotplug soit avec modprobe.conf.
    • [^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....

      Posté par  . Évalué à 3.

      > 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é".)
  • # Commentaire inutile...

    Posté par  . Évalué à 1.

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

Suivre le flux des commentaires

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