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
- L'annonce sur LKML (1 clic)
- Présentation de udev (pdf) (10 clics)
- La FAQ de udev (3 clics)
- udev vs. devfs (1 clic)
- Annonce sur kerneltrap (1 clic)
# Re: Udev atteint la maturité
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
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 iug . Évalué à -1.
[^] # Re: Udev atteint la maturité
Posté par puxor . Évalué à 0.
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 Prosper . Évalué à 1.
tu peux developper ?
[^] # Re: Udev atteint la maturité
Posté par puxor . Évalué à 3.
[^] # Re: Udev atteint la maturité
Posté par AlphA . Évalué à 9.
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 stork . Évalué à 0.
[^] # Re: Udev atteint la maturité
Posté par AlphA . Évalué à -1.
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 tgl . Évalué à 10.
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 NebuchadnezzaR . Évalué à 5.
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 ookaze . É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 ...
[^] # Re: Udev atteint la maturité
Posté par tgl . Évalué à 8.
Ç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 crevette . Évalué à 1.
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 Hobgoblins Master (Mastodon) . Évalué à 2.
[^] # Re: Maturité de devfs
Posté par crevette . Évalué à 1.
mais j'attends de personnes qui utilisent un GNU/linux une analyse un peu plus poussée :D.
[^] # Re: Maturité de devfs
Posté par puxor . Évalué à 5.
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 Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Maturité de devfs
Posté par crevette . Évalué à 1.
[^] # Re: Maturité de devfs
Posté par gnumdk (site web personnel) . Évalué à 1.
/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 Raphaël G. (site web personnel) . Évalué à 1.
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 Snark_Boojum . Évalué à 1.
On doit pas tout à fait vivre sur la même planète...
[^] # Re: Maturité de devfs
Posté par Xavier Jacquelin (site web personnel) . Évalué à 1.
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 Cyberdivad . Évalué à 5.
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 tgl . Évalué à 3.
> 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 NebuchadnezzaR . Évalué à 3.
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 mimo . Évalué à 2.
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 beck . Évalué à 3.
il arrive :-)
http://incoming.debian.org/(...)
[^] # Re: Maturité de devfs
Posté par Stephane Chauveau . Évalué à 3.
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 beck . Évalué à 1.
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 Arachne . Évalué à 1.
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 Mathieu Millet (site web personnel) . Évalué à 4.
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 tgl . Évalué à 5.
[^] # Re: Maturité de devfs
Posté par Daniel Caujolle-Bert . Évalué à 1.
[^] # Re: Maturité de devfs
Posté par Thomas Cataldo (site web personnel) . Évalué à 3.
# devfs est déclaré obsolète dans le kernel 2.6.
Posté par petit_bibi . Évalué à 4.
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.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Christophe Morvan (site web personnel) . Évalué à 9.
Il pourrait ne pas être idiot non plus de préciser que udev ne s'utilise QUE avec le noyau 2.6 (même si c'est précisé dans le README de l'archive).
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par tgl . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Stani . Évalué à 1.
Sous gentoo, udev est pleinement fonctionnel depuis quelques temps déjà.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par tgl . Évalué à 8.
À part ça, effectivement, le support de udev sous Gentoo est très bon. Azarah qui maintiens ça a d'ailleurs contribué régulièrement au développement de udev à mesure qu'il rencontrait de nouveaux problèmes, et Greg KH lui rôde maintenant sur gentoo-dev et bugs.gentoo.org et aide à fignoler les choses. Bref, un échange fructueux.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par kesako . Évalué à 4.
pour ceux qui ne comprendraient pas l'utilité, pensez au cartes pcmcia ( scsi ou autre ) des portables .
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Si le hard gère le hot plug PCI, il peut en effet être utile de rendre redondants certains périphs (cartes réseaux) et ainsi pouvoir changer le périph en vrac sans rebooter.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Bon ok, je conviens que cela ne permet pas de changer la carte dans la machine, mais permet de laisser disponible la machine sur le réseau :-)
Amicalement
Christophe
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
http://www.linuxdevices.com/articles/AT8382728818.html(...)
Amicalement
Christophe
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Ramso . Évalué à 2.
PCMCIA est déjà hotplug dans sa conception, contrairement à PCI.
Question subsidiaire : quels ports (internes ou externes) sont hotplug ou pas dans un PC ?
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Julien Wajsberg . Évalué à 2.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par fenril . Évalué à 1.
Pour l'ide, avec un bon rack et hdparm, ça le fait au montage, mais je n'ai pas encore trouvé comment faire reconnaitre un nouveau (différent) disque au (re)branchement.
Si il existe une solution (du genre "rescan-ide-bus") je suis preneur...
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Ramso . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Raphaël G. (site web personnel) . Évalué à 1.
pour les disque dur la méthod est simple : umount d toute les partoche du dur, hdparm -Y du device
la tu le demonte comme tu veut
théoriquement hdparm -z sur le disque dois relire la table des partoche et la régénérer
et un mount d'une partoche va relancer l'alim du disque dur /!\ 30 seconde d'arrêt du system lors de la remise en route du dique (faite gaffe a os alim real time!!! cdrecord, etc...)
Pour ce qui est des périphérique system, comme une carte réseau je sais pas trop si sa marche...
il dois faloir démonter le module de la carte, et après elle peut être remplacée, mais par contre j'ai aucune idée de la marche a suivre pour relire la table des cartes pci...
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par reno . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Euh, les cartes PCMCIA, ce n'est pas du 16 bits? (ISA)
Ce ne seraient pas plutôt les Cardbus qui sont concernées (PCI)?
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par gnumdk (site web personnel) . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par kesako . Évalué à 1.
mais essaye un branchement, debranchement , rebranchement avec une carte pcmcia scsi ou firewire par ex.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Ed GhZaaark . Évalué à 1.
Et c'est quoi l'alternative quand tu utilises un Linux.2.6?? Si les gens comme moi, n'ont jamais entendu parlé de udev...
Je trouve ce problème hallucinant, au niveau où se trouve le noyau linux, il ne dispose donc pas encore d'un gestionnaire de devices correct.
Toutefois, je ne vais pas cracher dans la soupe, devfs ne m'a pas encore trop dérangé car j'ai la manie de mettre un seul périph de type stockage à la fois, ou alors je connais l'ordre dans lequel je les ai branché.
+
ps: le mot le plus utilisé sur LinuxFr: "Troll", et ça commence sérieusement à me sortir par les trous de nez.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Boa Treize (site web personnel) . Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Ed GhZaaark . Évalué à -1.
vive les -1
rrrhha ces puristes!!!
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par Matthieu BENOIST . Évalué à 2.
# Comment ça se passe avec chroot?
Posté par Richard Van Den Boom . Évalué à 1.
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 Stani . Évalué à 1.
C'est plutôt un problème de lilo à mon sens...
[^] # Re: Comment ça se passe avec chroot?
Posté par iug . Évalué à 1.
[^] # Re: Comment ça se passe avec chroot?
Posté par Pierre-François Gomez . Évalué à 1.
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 Richard Van Den Boom . Évalué à 1.
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 Pierre-François Gomez . Évalué à 3.
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 gnumdk (site web personnel) . Évalué à 1.
Je pense que lilo marche tres bien sans mais dans le doute: mount -o bind!
[^] # Re: Comment ça se passe avec chroot?
Posté par Raphaël G. (site web personnel) . Évalué à 1.
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.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Comment ça se passe avec chroot?
Posté par tgl . Évalué à 1.
[^] # Re: Comment ça se passe avec chroot?
Posté par Snark_Boojum . Évalué à -1.
C'est une impression, ou vous êtes à côté de vos pompes dans ce fil de discussion?
[^] # Re: Comment ça se passe avec chroot?
Posté par Olivier (site web personnel) . Évalué à 1.
http://ruslug.rutgers.edu/~mcgrof/grub-images/(...)
[^] # Re: Comment ça se passe avec chroot?
Posté par Ramso . Évalué à 1.
Sinon, comme dis, tu créé les devices à la main ou avec le script MAKEDEV.
[^] # Re: Comment ça se passe avec chroot?
Posté par Richard Van Den Boom . Évalué à 1.
Merci, c'est ce que je voulais savoir.
Richard
# Re: Udev atteint la maturité
Posté par Jllc . Évalué à 1.
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 Stani . Évalué à 2.
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 ookaze . Évalué à 2.
- 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 Stani . Évalué à 1.
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 Raphaël G. (site web personnel) . Évalué à 1.
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 puxor . Évalué à 1.
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 __caffeine__ . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 1.
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 tgl . Évalué à 3.
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 tgl . Évalué à 2.
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 (site web personnel) . É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.
[^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....
Posté par Olivier LAHAYE (site web personnel) . Évalué à 1.
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 gnumdk (site web personnel) . Évalué à 4.
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 gnumdk (site web personnel) . Évalué à 1.
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 tgl . É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é".)
# Commentaire inutile...
Posté par Carbon Kid . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.