# [kernel] udev, qui l'a tester et adopter ? (Résolu)

## lithium

je vient tout juste de l'installer,n et je fait joujou avec dans /udev.

C'est ma fois fort plaisant, mais qui l'a adopter definitivement pour remplacer devfs ?

Et surtout comment vous avez fait  :Wink: Last edited by lithium on Sun Mar 07, 2004 2:30 pm; edited 4 times in total

----------

## navidson

ben a priori si tas pas de problemes de peripheriques non reconnus etc.... tu peux laisser devfs ca va rien changer....

----------

## TGL

Testé et adopté ici depuis fin janvier en gros. Rien de bien compliqué, il faut juste un baselayout récent, et un "emerge udev". La conf par défaut te donnera un nommage à la devfs des périphériques les plus classiques, et tu auras juste à ajouter éventuellement des règles pour les trucs genre clef usb ou scanner (et encore, tu peux te contenter du nommage par défaut). Par contre, ça bouge pas mal ces temps ci, donc prendre les versions testing peut être une bonne idée. Dans ton /etc/portage/package.keywords: 

```
sys-apps/baselayout   ~x86

sys-fs/udev   ~x86
```

(et n'oublie pas le etc-update après !)

Après, tu te débrouilles pour que devfs ne soit pas monté par le noyau au boot : 

 - soit tu désactives devfs dans le noyau

 - soit tu l'actives mais sans l'automontage

 - soit tu l'as déjà d'activé et avec automontage, donc tu passes l'option "devfs=nomount" au boot.

Si tu prends le dernier baselayout en date, fais qlqs essais avec RC_DEVICE_TARBALL="no" dans /etc/conf.d/rc pour voir si la gestion 100% dynamique du /dev fait l'affaire pour toi. Ce sera plus propre. Si tu te rends compte que tu as des devices non gérés que tu doit créer à la main, alors soit tu le fais depuis depuis un script d'init style /etc/conf.d/local.start, soit tu remets RC_DEVICE_TARBALL="yes" pour qu'ils soient enregistrés automatiquement. Perso je suis en 100% dynamique sans problème.

Ah, et puis évidemment, n'oublie pas de lancer le service hotplug: 

```
% rc-update add hotplug default
```

Ce qu'il faut bien voir, c'est que de toute façon ça ne coûte rien d'essayer. Revenir en devfs se fait très bien. Si tu gardes devfs dans le noyau, un simple paramètre de boot de permet de switcher de l'un à l'autre.

Si tu veux lire qlqs trolls sur le sujet et choper qlqs liens utiles, tu peux faire un tour ici : http://linuxfr.org/2004/03/03/15608.html et notament ce post: http://linuxfr.org/comments/360755.html

----------

## TGL

PS :  j'ai bien l'impression que je n'ai lu que ton titre et que j'ai fait ma réponse comme si tu n'avais même pas encore installée la chose. Désolé, je te laisse faire le tri.  :Smile: 

re-PS : est-ce que tu peut renommer ton post initial histoire de le faire coller à nos conventions. Une petite balise "[kernel]" en tête me paraitrait adaptée. Thanks.

----------

## lithium

Ah, c'est exactement le type de reponse que je cherchais, merci baucoup  :Smile: 

Je renomme le topic de suite.

PS : Euh... y'a pas de script dans init.d pour udev. Normal ? hotplug s'occupe de ça ?

----------

## TGL

 *lithium wrote:*   

> PS : Euh... y'a pas de script dans init.d pour udev. Normal ? hotplug s'occupe de ça ?

 

C'est /sbin/rc qui s'en occupe au boot. C'est presque la première chose qu'il fait. En gros, l'algo c'est :

 - si /dev est déjà peuplé (cas du devfs automonté par le noyau), alors bon, soit, on est en devfs.

 - sinon, si c'est un 2.6 qui est booté et qu'on a udev installé, alors peupler /dev/ avec hotplug & udev. Et lancer udevd s'il existe (jusqu'à récemment, y'avait pas de udevd. La différence n'est pas énorme, c'est juste un peu plus propre comme ça.)

 - sinon, se rabattre sur devfs.

Pour les périphériques détectés après le boot (branchés après, ou bien quand le module est chargé seulement plus tard, etc.), le service hotplug envoye des évenement à udevd.

Donc pas de service udev, et c'est normal.  :Smile: 

----------

## lithium

Donc tout ce que j'ai a faire dans mon cas :

```
  │ │      [*] /proc file system support                                  │ │

  │ │      [*] /dev file system support (OBSOLETE)                        │ │

  │ │      [ ]   Automatically mount at boot                              │ │

  │ │      [ ]   Debug devfs                                              │ │

 
```

c'est rebooter ?

----------

## TGL

Pour un premier test, et si ton baselayout est assez récent, oui. Vérifie juste que tu as bien remis udev_root="/dev/" dasn /etc/udev/udev.conf si avant tu utilisait /udev/ dans tes tests.

Surveille le boot, les première lignes avec des étoiles vertes, elles devraient t'indiquer des trucs du genre "populating /dev using udev", etc. Si là ça cause de devfs à la place, alors c'est raté  :Smile: 

----------

## lithium

sys-apps/baselayout-1.8.6.13  :Smile: 

Merci baucoup, je vais essayer alors... il faut que je nettoie /dev d'abord ?

----------

## TGL

Non, le /dev de devfs est volatile, il est tout propre au reboot. Celui que te fera udev aussi d'ailleurs, donc si tu dois revenir à devfs, ça ne posera pas de problème non plus.

----------

## lithium

Bon, c'est super, ça marche nikel  :Smile: 

Par contre j'ai passer RC_DEVFSD_STARTUP="yes" à no dans /etc/conf.d/rc

Merci Mille fois TGL  :Smile: 

----------

## TGL

Cool  :Smile: 

 *lithium wrote:*   

> Par contre j'ai passer RC_DEVFSD_STARTUP="yes" à no dans /etc/conf.d/rc

  Ça doit pas être la peine je crois. Ça c'est plus pour choisir entre devfs et un /dev/ statique pour les kernels 2.4, mais de toute façon udev a la priorité sur les 2.6 quand c'est possible. 

 *lithium wrote:*   

> Merci Mille fois TGL 

  Pas d'quoi  :Wink: 

Oh, et puis tant qu'on parle de udev, une bonne nouvelle : Greg K.H., le dévelopeur d'udev, rejoins les rangs des dévelopeurs Gentoo. Azarah, le mainteneur de baselayout et de ce genre de truc de base sur la Gentoo, avait en effet commencé très tôt à intégrer udev dans la distrib', et leur collaboration a eveillé l'intérêt de Greg pour la distrib. Moi je dis qu'avec ça, l'avenir de udev sous Gentoo ne peut être que radieux.  :Cool: 

(Bon alors pour ceux qui n'auraient pas compris le " :Cool: ", c'est à cause de l'avenir radieux, faut se protéger des rayons... Bon, ok, je me tais et je retourne jouer à kobodeluxe alors...  :Embarassed: )

----------

## lithium

Damn, j'ai un ch'tit souvis maintenant, au boot je doit killer udevd et lancer udevstart 

pour qu'il recommence a me creer mes noeuds a la demande, notament ceux d'alsa :/

Un soluce ?

----------

## guilc

udev adopté sur mon portable : tout marche très bien, et j'ai un /dev tout propre.

Par contre, sur mon fixe, udev pose probleme avec ma carte tv (bt878 classique) : quel que soit le soft utilisé, le mode secam disparait (au redémarrage avec devfs, totu rentre dans l'ordre) ! pas très pratique pour capter la TV française :p Sinon, tout le reste fonctionne egalement très bien

Donc au bilan, udev très prometteur, mais peut-etre pas encore completement fini et exploitable a 100%  :Smile: 

Mais quand je pense que sur debian, devfs est meme pas mis par défaut, et quand je regarde comment un /dev avec udev est propre, avec juste ce qui est effectivement installé, et bien je plains les "debianeux"  :Smile: ))

----------

## TGL

Ouais, j'avais pas rebooté depuis longtemps en fait, et je viens d'essayer et j'ai eu des soucis similaires. On dirait que la technique "udevd/udevsend" pose encore un peu problème en fait. Dans ce bug report, j'ai trouvé un le workaround pour utiliser "udev" au lieu de "udevsend" pour les évenements hotplug (càd à ce qu'il y avait jusqu'à la version 018, celle que j'utilisais en fait encore) : 

```
% ln -snf /sbin/udev /etc/hotplug.d/default/udev.hotplug
```

 Ça l'a fait pour moi, et pour vous ?

Pour le coup du mode secam, ça peut-être un problème différent. Soit des devices manquant, soit de mauvaises permissions. Mon conseil serait de faire, sous le système en devfs : 

```
% strace ton_soft_de_tv 2>&1 | grep /dev/
```

 pour voir les devices utilisés. Après, tu fais des "ls -l" sur ces devices pour voir leurs permissions, tu gardes bien tout ça dans un fichier, tu reboot en udev, et tu joues au jeu des différences. Ça devrait te mettre sur la voie.

----------

## jcc

http://www.gentoo.org/doc/en/udev-guide.xml

:)

----------

## lithium

TGL : c'est exactement ça, par contre j'utilise la derniere version (sys-fs/udev-021).

Vais peut etre tenter l'astuce que tu donne.

Merci

----------

## TGL

 *lithium wrote:*   

> par contre j'utilise la derniere version (sys-fs/udev-021).

  Moi aussi maintenant, mais le pb est exactement le même de la 018-r1 à la 021, bref toutes les versions après la 018, qui était la dernière à ne pas encore utiliser udevd.

----------

## guilc

Pour la TV, effectivement, c'est un probleme de droits :

sous devfs, /dev/v4l/video0 est en 660 mon_user:video

sous udev, 660, mais root:video.

J'ai donc tout simplement rajouté mon user au groupe video  :Smile: 

Reste encore un petit probleme qui tient sans doute a la maturité de udev :

le lien sur mon lecteur DVD n'est pas fait, donc j'ai créé ln -s /dev/sr0 /dev/dvd, ce qui m'oblige a sauvegarder la tarball

Avant d'arriver a lire un DVD, je dois l'insérer et retirer plusieurs fois avant qu'il soit détecté, que ce soit par ogle, totem ou mplayer (sinon, ces logiciels disent qu'il n'y a pas de DVD dans le lecteur : Can't read /dev/dvd...)

Je teste plus a fond maintenant  :Smile: 

----------

## lithium

TGL : Encore merci, ça marche super  :Smile: 

----------

## TGL

 *guilc wrote:*   

> le lien sur mon lecteur DVD n'est pas fait

  Oh, je suis à peu près sûr que tu pourrais facilement rajouter une règle pour ça dans /etc/udev/udev.rules. Regarde cette page pour la syntaxe.

 *guilc wrote:*   

> donc j'ai créé ln -s /dev/sr0 /dev/dvd, ce qui m'oblige a sauvegarder la tarball, ce qui m'oblige a sauvegarder la tarball

  Au pire, si tu n'arrives pas à créer la règle qui va bien, tu peux aussi coller cette création de lien dans ton /etc/conf.d/local.start plutôt que d'utiliser le tarball.

 *guilc wrote:*   

> Avant d'arriver a lire un DVD, je dois l'insérer et retirer plusieurs fois avant qu'il soit détecté, que ce soit par ogle, totem ou mplayer (sinon, ces logiciels disent qu'il n'y a pas de DVD dans le lecteur : Can't read /dev/dvd...)

  Ça par contre c'est bizarre. Si /dev/dvd est un lien vers ton vrai device, et que ce vrai device est bien le même que quand tu utilises devfs (même major/minor et même permissions), alors il n'y a aucune raison que ça ne fonctionne pas exactement pareil. Udev ne s'occupe que de la création des devices, et devfs aussi, mais ils ne jouent aucun rôle dans leur utilisation. Là encore, jouer au différences entre les deux configurations devraient te donner l'explication.

----------

## zarasoustra17

Moi, j'ai remarqué qu'il ne crée pas les périphériques à la volée dans /dev.

Si je veux utiliser ma clé USB(que j'ai configurée dans /etc/udev/udev.rules), mon joystick ou même mon imprimante je suis obligé de les brancher (ou allumer) avant le boot alors que qu'avec devfs ils étaient créés "en live" avec hotplug.Il va falloir que je potasse le fonctonnement d'Hotplug et de udev pour rajouter des scripts qui vont bien.

A part ça, ça roule.

----------

## TGL

Bah justement si, il devrait les créer (et en plus, "ça marche chez moi"(tm)). Tu as bien le service hotplug démarré ? Si oui, quand tu branche un device, hotplug devrait le détecter et réveiller udev pour que ce dernier crée le noeud, c'est ça le principe. Donc soit :

 - ta règle udev n'est pas correcte et donc udev ne trouve rien à faire

 - c'est encore udevsend/udevd qui font des leurs, et tu peux essayer le truc que j'indiquais un peu plus haut pour utiliser la commande udev à la place

 - heu, sinon je vois pas :/

Enfin, au moins pour les devices usb bien sûr, ou tout autre port compatible hotplug. Si ton imprimante est sur port // par contre, alors hotplug ne vois rien, ça c'est pas nouveau.

----------

## ThE_TemPLaR

J'ai installé udev, j'ai lu les quelques docs (ça m'a permit de régler le problème avec ppp0) mais j'ai une petite question :

- /dev/fb0 peut-il être crée dynamiquement ?

J'ai remarqué qu'il n'était pas là quand j'ai lancé une vidéo sous une console :/

----------

## TGL

Hmm... il semblerait que les drivers framebuffer ne soit toujours pas compatible avec sysfs (et pas d'entrée dans sysfs, c'est pas de device avec udev). Essaye voir avec le patch référencé dans ce post : https://forums.gentoo.org/viewtopic.php?p=924140

(je vais tester aussi de mon côté pour voir)

----------

## zarasoustra17

J'ai réinstallé hotplug (même version) et ça marche!!

----------

## TGL

C'est spé... Peut-être un etc-update qui était mal passé la première fois ? Enfin bon on s'en fout, le tout c'est que ça marche.  :Smile: 

----------

## ThE_TemPLaR

Je vais tenter de l'appliquer sur mon 2.6.3...

J'espère que ça ne dépend pas d'un autre patch Gentoo...

----------

## guilc

Je ne comprends pas bien...

Pour avoir les bons lien, j'ai ajouté ça a mon udev.rules :

```
BUS="ide", KERNEL="hdc", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"

BUS="ide", KERNEL="hdd", NAME="%k", SYMLINK="cdrw cdroms/cdrom%n"
```

Et les liens /dev/dvd et /dev/cdrom ne sont pas créés !

j'ai aussi essayé en remplaçant les %n par leurs valeurs, (repectivement 0 et 1), mais a ce que j'ai compris, ce n'est pas la peine, et de toute façon, ça ne change rien...

Je ne comprends pas bien pourquoi... Une idée ? Car ça serait bete d'utiliser la tarball pour ça  :Smile: 

----------

## TGL

Le truc important, c'est que udev utilise la 1ère bonne règle qu'il trouve. Donc si tu as gardé la règle "hd*" qui crée les liens à la devfs, alors ta version personnalisée pour hdc et hdd doit être avant. Moi j'ai gardé l'appel au script devfs histoire de ne même pas me poser de question, mais ça n'a rien d'indispensable, enfin bref ça me donne (pour un combo cdrom/cdrw/dvd, donc trois liens sur le même truc histoire de pas avoir à reconfigurer quoi que ce soit): 

```
[...]

###########################################################

#

# For devfs similar /dev layout (neater)

#

###########################################################

# TGL: more symlinks for the dvd/cdrw combo

BUS="ide", KERNEL="hdc", PROGRAM="/etc/udev/scripts/ide-devfs.sh %k %b %n", NAME="%k", SYMLINK="%c{1} %c{2} cdrom cdrw dvd"

# devfs-names for ide-devices (uncomment only one)

#  /dev/ide/.../{disc,cd} and /dev/{cdroms,discs}/* type names

BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/scripts/ide-devfs.sh %k %b %n", NAME="%k", SYMLINK="%c{1} %c{2}"

[...]
```

----------

## guilc

Ok ! je n'avais pas bien compris ça.

Effectivement, en mettant les regles poru le dvd avant la regle générique hd* / ide-devfs, ça marche  :Smile: 

merci !

----------

## zarasoustra17

 *Quote:*   

> C'est spé... Peut-être un etc-update qui était mal passé la première fois ? Enfin bon on s'en fout, le tout c'est que ça marche.

 

En fait, c'est que j'ai un port USB sur 8 sur lequel ça ne marche pas et c'est pile sur celui là que j'ai essayé, le port n'est tout simplement pas détecté (sous devfs aussi), mon Hub doit avoir les soudures fatiguées!!!

Sinon pour la clé USB, j'ai repris le script et les règles ide que j'ai transposées en scsi(mass storage utilise l'émulation scsi) et ça marche au poil, avis aux amateurs.

----------

