le meilleur automounter ?

On Mon, 27 Sep 2004 22:17:26 +0200, Hugolino wrote:

Bonsoir,

Grâce qu ng, j'ai (presque) résolu mon problème de Clé USB qui ne
voulait pas se mounter.
(Je poste la solution du problème dès que j'ai pigé comment faire un
diff entre le fichier de config du noyau qui ne fonctionne pas et celui
qui fonctionne).

Le problème actuel est que selon /ect/fstab, la CléUSB est reconnue
comme /dev/sda1 et l'APN est reconnu comme /dev/sdb1.
Mais cela necessite que je branche la clé USB avant l'APN.

Je cherche donc la meilleure solution d'automontage.

J'ai entendu parlé (en gogolisant les archive du ng) de autofs et de
udev. Mais quelques questions demeurent:

* Sont-ils complémentaires ?
* Si non, lequel est-il censés être maintenu dans l'avenir ?

autofs est, à ce que j'en connait, du moins, plutôt utilisé (et très
efficace) pour les montages réseaux: montage automatique des home
directory au login, montage automatique des partages des autres machines
lors de l'exploration des répertoires (en faisant cd xxx, pour être
clair). Je ne l'ai jamais vu configuré pour gérer correctement les
montages de disques amovibles.

udev est complètement différent et ne réponds pas non plus à ton
problème: c'est un utilitaire qui permet de créer les entrées de device
dans /dev quand ceux-ci apparaissent ou disparaissent de la machine. C'est
le successeur de devfs.
Il peut sans doute être utilisé, couplé avec hotplug (dont il dépend,
de toute façon), pour faire du montage automatique de disques amovibles
mais c'est un outil beaucoup plus générique que celà.
Les supermount (que je déteste, mais bon...) et autres doivent pouvoir
s'en accomoder.

Hugolino a écrit :

Bonsoir,

Salut,

Grâce qu ng, j'ai (presque) résolu mon problème de Clé USB qui ne
voulait pas se mounter.
(Je poste la solution du problème dès que j'ai pigé comment faire un
diff entre le fichier de config du noyau qui ne fonctionne pas et celui
qui fonctionne).

Le problème actuel est que selon /ect/fstab, la CléUSB est reconnue
comme /dev/sda1 et l'APN est reconnu comme /dev/sdb1.
Mais cela necessite que je branche la clé USB avant l'APN.

Je cherche donc la meilleure solution d'automontage.

C'est celle qu'on maîtrise le mieux

J'ai entendu parlé (en gogolisant les archive du ng) de autofs et de
udev. Mais quelques questions demeurent:

* Sont-ils complémentaires ?

oui...

autofs permet de faire plein de montage automatique et très, très
paramétrables. J'avais fait il y a près de 5 ans une petite doc, qui
traine toujours sur :
http://julien.salgado.free.fr/
qui permet d'avoir quelques idées sur la syntaxe et les possibilités de
autofs.

udev permet d'avoir une nomenclature homogène de /dev/ en fonction de la
nature du périphérique.

Si on couple les deux on peut faire en sorte que le montage en fonction
de paramètres... comme par exemple sur :
http://users.actrix.co.nz/michael/usbmount.html

* Si non, lequel est-il censés être maintenu dans l'avenir ?


Merci de votre aide

--
Julien

Le 28 Sep 2004 11:07:06 GMT, Julien Salgado a écrit:

Hugolino a écrit :

Bonsoir,

Salut,

Grâce qu ng, j'ai (presque) résolu mon problème de Clé USB qui ne
voulait pas se mounter.
(Je poste la solution du problème dès que j'ai pigé comment faire un
diff entre le fichier de config du noyau qui ne fonctionne pas et celui
qui fonctionne).

Le problème actuel est que selon /ect/fstab, la CléUSB est reconnue
comme /dev/sda1 et l'APN est reconnu comme /dev/sdb1.
Mais cela necessite que je branche la clé USB avant l'APN.

Je cherche donc la meilleure solution d'automontage.

C'est celle qu'on maîtrise le mieux

Celle qu'on a le mieux RTFMé ? :)

(Ce que je pige pas, c'est l'endroit entre /etc/auto.master et
/etc/auto.misc (je cause autofs, là) où je vais dire que ma clé est en
vfat et mon APN en msdos)

J'ai entendu parlé (en gogolisant les archive du ng) de autofs et de
udev. Mais quelques questions demeurent:

* Sont-ils complémentaires ?

oui...

autofs permet de faire plein de montage automatique et très, très
paramétrables. J'avais fait il y a près de 5 ans une petite doc, qui
traine toujours sur :
http://julien.salgado.free.fr/
qui permet d'avoir quelques idées sur la syntaxe et les possibilités de
autofs.

Je vais donc RTFMé

udev permet d'avoir une nomenclature homogène de /dev/ en fonction de la
nature du périphérique.

Si on couple les deux on peut faire en sorte que le montage en fonction
de paramètres... comme par exemple sur :
http://users.actrix.co.nz/michael/usbmount.html

Encore un RTFM, et le néo-zélandais a l'air de s'être bien déchiré, va
falloir le suivre...

Merci de ton aide, mon cher Julien (docteur devrais-je dire ?)



--
Hugo NPN (i --> ee)
Viens chez moi, je te montrerai mon e2fsck ...
-+- LF in Guide du linuxien pervers - jusqu'où irez vous avec nous ? -+-

Le Mon, 27 Sep 2004 23:30:05 +0200, no_spam a écrit:

On Mon, 27 Sep 2004 22:17:26 +0200, Hugolino wrote:
[snip]

Je cherche donc la meilleure solution d'automontage.

autofs est, à ce que j'en connais, du moins, plutôt utilisé (et très
efficace) pour les montages réseaux: montage automatique des home
directory au login, montage automatique des partages des autres machines
lors de l'exploration des répertoires (en faisant cd xxx, pour être
clair).

C'est ce que j'ai cru en voir en potassant la doc.

Je ne l'ai jamais vu configuré pour gérer correctement les montages
de disques amovibles.

Arf, voilà qui m'arrange :(
Mais ne contredirais-tu pas ce cher Julien en soutenant de tels propos ?

udev est complètement différent et ne réponds pas non plus à ton
problème:

Argll :(

c'est un utilitaire qui permet de créer les entrées de device dans
/dev quand ceux-ci apparaissent ou disparaissent de la machine. C'est
le successeur de devfs.

C'est ce que j'en avais retenu quand j'avais jeté un oeil à la doc.

Il peut sans doute être utilisé, couplé avec hotplug (dont il dépend,
de toute façon), pour faire du montage automatique de disques amovibles
mais c'est un outil beaucoup plus générique que celà.

Il y a un truc que je ne pige pas, tu dis d'abord que «udev... ne répond
pas à [mon] problème» puis qu'il peut être «couplé avec hotplug» pour
faire ce que je veux ?!??

De plus, qu'entends-tu par «plus générique que ça»

Les supermount (que je déteste, mais bon...) et autres doivent pouvoir
s'en accomoder.

Gnî ?!??


Peut-être dois-je préciser ma pensée:
J'ai une clé USB et j'ai la ligne correspondante dans /etc/fstab:
/dev/sda1 <-> /mnt/CléUSB <-> vfat
et un APN dont la ligne de /etc/fstab correspond à:
/dev/sdb1 <-> /mnt/APN <-> msdos

Et je voudrais bien que ohci_hcd, usb-storage et leurs potes fassent le
ménage entre eux pour que je ne sois pas obliger de mounter la Clé avant
l'APN, puis de démounter l'APN avant la clé, puis de me souvenir au bout
d'une semaine quel dev je dois mounter ou démounter avant de remounter
ou démonter l'autre. Ç'est comme ça qu'on en vient à rebooter et à
bouziller l'uptaïm.


Merci Yoyo de ta contribution (j'attends que ceux qui ont réussi à faire
marcher udev pour atteindre mon but se manifeste (j'ai les noms des
meneurs))


--
<html><p>Comme promis, un petit mail pour te rappeler de m'envoyer les
fichiers de configuration du modem. <p>En plus t'a mon mail pro,
si jamais t'a un truc urgent ( je consulte pas wanadoo tous les jours).
-+- YD in Guide du linuxien pervers - "Toujours bien tenir ses promesses"

[ ATTENTION LONGUES LIGNES INSIDE ! Désolé ]

On 28 sep 2004, hugolino@fri.fr wrote:

udev permet d'avoir une nomenclature homogène de /dev/ en
fonction de la nature du périphérique.

Si on couple les deux on peut faire en sorte que le montage
en fonction de paramètres... comme par exemple sur :
http://users.actrix.co.nz/michael/usbmount.html

Encore un RTFM, et le néo-zélandais a l'air de s'être bien
déchiré, va falloir le suivre...

C'est très simple udev. Suffit de coupler ça avec systool et tu
verras. C'est très souple et ne demande que 5 minutes
d'attention.

Premièrement voici comment moi, je gère mon APN, ma clé USB, mon
reader de carte, la webcam etc...

Donc je me suis installer udev (apt-get udev). Puis je me suis
créer un fichier personnel dans /etc/udev/rules.d qui regroupe
mes personnalisations (pratique). Cette méthode a l'avantage de
ne pas être effacée par une mise à jour du paquet. Le fichier je
l'ai nommé '10-local.rules'. [petite note: udev charge tous les
fichiers qu'il peut trouver dans /etc/udev/rules.d/].

Maintenant, il faut penser à installer la suite d'outils
sysfsutils (dont l'outil systool):

,----[ dpkg -s sysfsutils ]
| Package: sysfsutils
| Status: install ok installed
| Priority: extra
| Section: utils
| Installed-Size: 41
| Maintainer: Martin Pitt <mpitt@debian.org>
| Architecture: i386
| Version: 1.1.0-1
| Depends: libc6 (>= 2.3.2.ds1-4), libsysfs1
| Description: Utility for querying sysfs
| Sysfs is a virtual file system in Linux kernel 2.5+ that provides a
| tree of system devices. This package provides the program 'systool' to query
| it: it can list devices by bus, class, and topology.
| .
| If you need sysfs queries in own programs, then you may want to use the
| libsysfs library directly (package libsysfs-dev).
|
`----

Par exemple systool est capable de te lister tous les
périphériques du bus USB...

Cet outil va donc te permettre d'isoler et de reconnaître à coup
sûr tout matériel se connectant à ton ordinateur.

Il suffit ensuite de remplir ton fichier de règles udev suivant
tes besoins. Pour info, voici le mien (enfin un extrait seulement):

,----[ 10-local.rules ]
| # Creer les liens cdrom et dvdrom
| BUS="ide", KERNEL="hdc", NAME="%k", GROUP="cdrom", MODE="0660", SYMLINK="cdrom dvd"
|
| #memory stick (la MS ne fonctionne plus :()
| BUS="usb", SYSFS{Product}="USB Memory Stick Slot", KERNEL="sd?1", NAME='%k", SYMLINK=""mstick"
|
| #appareil photo doit arriver sur /dev/photo1
| BUS="scsi", SYSFS_vendor="OLYMPUS*", NAME="photo%n"
|
| #cle USB doit arriver sur /dev/usbkey1
| BUS="scsi", SYSFS_vendor="Generic*", NAME="usbkey%n"
|
| #Webcam
| BUS="usb", SYSFS{name}="Logitech QuickCam Pro 3000", NAME="webcam%n", SYMLINK="usb/webcam%n"
`----

Pour obtenir la ligne de la clé USB (par exemple), voici comment
j'ai procéder:

,----[ systool -b scsi -c scsi_device -v ]
| Bus = "scsi"
|
| Device = "0:0:0:0"
| Device path = "/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0/host0/0:0:0:0"
| delete = <store method only>
| detach_state = "0"
| device_blocked = "0"
| max_sectors = "240"
| model = "Traveling Disk "
| queue_depth = "1"
| rescan = <store method only>
| rev = "1.11"
| scsi_level = "3"
| state = "running"
| timeout = "30"
| type = "0"
| vendor = "Generic "
|
| Class = "scsi_device"
|
| Class Device = "0:0:0:0"
| Class Device path = "/sys/class/scsi_device/0:0:0:0"
|
| Device = "0:0:0:0"
| Device path = "/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0/host0/0:0:0:0"
| delete = <store method only>
| detach_state = "0"
| device_blocked = "0"
| max_sectors = "240"
| model = "Traveling Disk "
| queue_depth = "1"
| rescan = <store method only>
| rev = "1.11"
| scsi_level = "3"
| state = "running"
| timeout = "30"
| type = "0"
| vendor = "Generic "
|
|
`----

Qui me liste tous les paramètres de tous les périphériques SCSI
présent sur ma machine.

A partir de cette liste, je suis en mesure d'isoler les
propriétés de ma clé.

Il ne me reste ensuite plus qu'à donner cette information à udev:

,----
| BUS="scsi", SYSFS_vendor="Generic*", NAME="usbkey%n"
`----

La construction du SYSFS_vendor permet de dire que l'on veut
prendre le paramètre vendor du périphérique comme identifiant de
notre clé. Ensuite udev va se charger à chaque fois qu'il le
détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1
(dans le cas d'une seule clé). udev s'occupera également de
supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.

Preuve (reconnaissance de la clé):

,----
| Sep 29 12:14:10 totoz kernel: usb 2-2: new full speed USB device using address 2
| Sep 29 12:14:10 totoz kernel: SCSI subsystem initialized
| Sep 29 12:14:10 totoz kernel: Initializing USB Mass Storage driver...
| Sep 29 12:14:10 totoz kernel: scsi0 : SCSI emulation for USB Mass Storage devices
| Sep 29 12:14:10 totoz kernel: Vendor: Generic Model: Traveling Disk Rev: 1.11
| Sep 29 12:14:10 totoz kernel: Type: Direct-Access ANSI SCSI revision: 02
| Sep 29 12:14:11 totoz kernel: USB Mass Storage device found at 2
| Sep 29 12:14:11 totoz kernel: usbcore: registered new driver usb-storage
| Sep 29 12:14:11 totoz kernel: USB Mass Storage support registered.
| Sep 29 12:14:10 totoz usb.agent[5671]: usb-storage: loaded successfully
| Sep 29 12:14:11 totoz scsi.agent[5750]: disk at /devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0/host0/0:0:0:0
| Sep 29 12:14:11 totoz kernel: SCSI device sda: 258048 512-byte hdwr sectors (132 MB)
| Sep 29 12:14:11 totoz kernel: sda: assuming Write Enabled
| Sep 29 12:14:11 totoz kernel: sda: assuming drive cache: write through
| Sep 29 12:14:11 totoz udev: configured rule in '/etc/udev/rules.d/10-local.rules' at line 11 applied, 'sda' becomes 'usbkey%n'
| Sep 29 12:14:11 totoz udev: creating device node '/dev/usbkey'
| Sep 29 12:14:11 totoz kernel: /dev/scsi/host0/bus0/target0/lun0: p1
| Sep 29 12:14:11 totoz kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
| Sep 29 12:14:11 totoz udev: configured rule in '/etc/udev/rules.d/10-local.rules' at line 11 applied, 'sda1' becomes 'usbkey%n'
| Sep 29 12:14:11 totoz udev: creating device node '/dev/usbkey1'
`----

Charge à toi ensuite de dire à hotplug de monter ce device dans
/media/cleusb si tu le souhaites.

Voili, voilou.

Pour l'entrée de ma webcam, j'ai peu ou proue suivi la même
méthode et pareil pour le reste.

Le truc est de bien choisir le paramètre sur lequel s'appuyer
pour la détection du type de matériel par udev.

J'espère que ça va t'aider un peu.
--
Hito no kokoro wa kawareru mono

On Wed, 29 Sep 2004 12:29:29 +0200, Xavier Maillard wrote:

[ ATTENTION LONGUES LIGNES INSIDE ! Désolé ]

On 28 sep 2004, hugolino@fri.fr wrote:

udev permet d'avoir une nomenclature homogène de /dev/ en
fonction de la nature du périphérique.

Si on couple les deux on peut faire en sorte que le montage
en fonction de paramètres... comme par exemple sur :
http://users.actrix.co.nz/michael/usbmount.html

Encore un RTFM, et le néo-zélandais a l'air de s'être bien
déchiré, va falloir le suivre...

C'est très simple udev. Suffit de coupler ça avec systool et tu
verras. C'est très souple et ne demande que 5 minutes
d'attention.
[...]

,----[ 10-local.rules ]
| # Creer les liens cdrom et dvdrom
| BUS="ide", KERNEL="hdc", NAME="%k", GROUP="cdrom", MODE="0660", SYMLINK="cdrom dvd"
|
| #memory stick (la MS ne fonctionne plus :()
| BUS="usb", SYSFS{Product}="USB Memory Stick Slot", KERNEL="sd?1", NAME='%k", SYMLINK=""mstick"
|
| #appareil photo doit arriver sur /dev/photo1
| BUS="scsi", SYSFS_vendor="OLYMPUS*", NAME="photo%n"
|
| #cle USB doit arriver sur /dev/usbkey1
| BUS="scsi", SYSFS_vendor="Generic*", NAME="usbkey%n"
|
| #Webcam
| BUS="usb", SYSFS{name}="Logitech QuickCam Pro 3000", NAME="webcam%n", SYMLINK="usb/webcam%n"
[...]

La construction du SYSFS_vendor permet de dire que l'on veut
prendre le paramètre vendor du périphérique comme identifiant de
notre clé. Ensuite udev va se charger à chaque fois qu'il le
détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1
(dans le cas d'une seule clé). udev s'occupera également de
supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.

Utiliser les strings "Vendor" et "Product" n'est pas vraiment une idée
géniale pour identifier un périphérique USB: il faut savoir que les
chaines de description sont optionnelles et libres en USB. Ce qui fait
qu'elles sont parfois vide, parfois rempli avec n'importe quoi et il n'est
pas rare qu'elles changent entre 2 releases de firmware. De plus, un
constructeur vend souvent plus d'un périphérique USB, de types
complètement différent.
Il faut utiliser les attributs DeviceClass, DeviceProtocol et
DeviceSubclass (comme défini dans la norme USB) pour repérer les
périphériques génériques (hubs, storages, ...) (voire les
classes/protocoles/sous-classes des interfaces, mais c'est plus compliqué
et plus rare) et utiliser les VendorID, ProductID et revisionID
numériques pour les autres. C'est la seule méthode réellement fiable
d'identification, pour l'USB au moins.
Je n'ai jamais utilisé udev pour celà, mais ayant pas mal planché sur
l'USB, j'ai vu pas mal des horreurs qui trainent dans ce monde là...

On 29 sep 2004, no spam wrote:

Utiliser les strings "Vendor" et "Product" n'est pas vraiment
une idée géniale pour identifier un périphérique USB: il faut
savoir que les chaines de description sont optionnelles et
libres en USB. Ce qui fait qu'elles sont parfois vide, parfois
rempli avec n'importe quoi et il n'est pas rare qu'elles
changent entre 2 releases de firmware. De plus, un constructeur
vend souvent plus d'un périphérique USB, de types complètement
différent. Il faut utiliser les attributs DeviceClass,
DeviceProtocol et DeviceSubclass (comme défini dans la norme
USB) pour repérer les périphériques génériques (hubs, storages,
...) (voire les classes/protocoles/sous-classes des interfaces,
mais c'est plus compliqué et plus rare) et utiliser les
VendorID, ProductID et revisionID numériques pour les autres.
C'est la seule méthode réellement fiable d'identification, pour
l'USB au moins. Je n'ai jamais utilisé udev pour celà, mais
ayant pas mal planché sur l'USB, j'ai vu pas mal des horreurs
qui trainent dans ce monde là...

Je suis d'accord avec ce que tu dis (n'y connaissant pas grand
chose). Néanmoins je pars du principe que je ne change *jamais*
de matériel et surtout ne mets jamais les firmware à jour. Donc
dans mon cas (1 clé USB, 1 APN, ...), il y a très peu de chances
que quoique ce soit ne change. C'est pour cette raison que j'ai
procédé comme ça :)

P.S: merci pour tes explications
--
Xavier Maillard

main(){printf(&unix["21%six12"],(unix)["have"]+"fun"-0x60);}

On Thu, 30 Sep 2004 01:32:27 +0200, Xavier Maillard wrote:

On 29 sep 2004, no spam wrote:

Utiliser les strings "Vendor" et "Product" n'est pas vraiment
une idée géniale pour identifier un périphérique USB: il faut
savoir que les chaines de description sont optionnelles et
libres en USB. Ce qui fait qu'elles sont parfois vide, parfois
rempli avec n'importe quoi et il n'est pas rare qu'elles
changent entre 2 releases de firmware. De plus, un constructeur
vend souvent plus d'un périphérique USB, de types complètement
différent. Il faut utiliser les attributs DeviceClass,
DeviceProtocol et DeviceSubclass (comme défini dans la norme
USB) pour repérer les périphériques génériques (hubs, storages,
...) (voire les classes/protocoles/sous-classes des interfaces,
mais c'est plus compliqué et plus rare) et utiliser les
VendorID, ProductID et revisionID numériques pour les autres.
C'est la seule méthode réellement fiable d'identification, pour
l'USB au moins. Je n'ai jamais utilisé udev pour celà, mais
ayant pas mal planché sur l'USB, j'ai vu pas mal des horreurs
qui trainent dans ce monde là...

Je suis d'accord avec ce que tu dis (n'y connaissant pas grand
chose). Néanmoins je pars du principe que je ne change *jamais*
de matériel et surtout ne mets jamais les firmware à jour. Donc
dans mon cas (1 clé USB, 1 APN, ...), il y a très peu de chances
que quoique ce soit ne change. C'est pour cette raison que j'ai
procédé comme ça :)

OK, je comprends, moi, je fais pas mal de tests de device USB sous Linux,
je me méfie donc pas mal...
Mais fait quand même attention si tu utilise des devices dont le firmware
est téléchargé au chargement du module (c'est le cas de la plupart des
dongle Wifi et bluetooth et de certains USB-ethernet) quand tu met à
jour ton noyau: si le firmware est mis à jour (ce qui n'est pas
forcément simple à savoir sans regarder les sources), les strings
peuvent changer...

P.S: merci pour tes explications

De rien. C'est un peu le but du groupe, non ? ;-)

On 30 sep 2004, no spam wrote:

Je suis d'accord avec ce que tu dis (n'y connaissant pas
grand chose). Néanmoins je pars du principe que je ne change
*jamais* de matériel et surtout ne mets jamais les firmware à
jour. Donc dans mon cas (1 clé USB, 1 APN, ...), il y a très
peu de chances que quoique ce soit ne change. C'est pour
cette raison que j'ai procédé comme ça :)

OK, je comprends, moi, je fais pas mal de tests de device USB
sous Linux, je me méfie donc pas mal... Mais fait quand même

Forcément... :/

attention si tu utilise des devices dont le firmware est
téléchargé au chargement du module (c'est le cas de la plupart
des dongle Wifi et bluetooth et de certains USB-ethernet) quand
tu met à jour ton noyau: si le firmware est mis à jour (ce qui
n'est pas forcément simple à savoir sans regarder les sources),
les strings peuvent changer...

Disons que je n'utilise pas ce genre d'appareil et de toute
façon, un changement de noyau, pour moi s'accompagne très souvent
d'une lecture très soigneuse des changements voir même du source
des choses qui me paraissent critiques (ACPI, et autres
joyeusetés). Autant dire que je ne change pas comme ça :/

--
Xavier Maillard| "Stand Back! I'm a programmer!"
.0. zedek@gnu-rox.orgz|
..0 (+33) 326 770 221 | Webmaster, emacsfr.org
000 PGP : 0x1E028EA5 | Membre de l' APRIL

Le Wed, 29 Sep 2004 23:10:38 +0200, no_spam a écrit:

On Wed, 29 Sep 2004 12:29:29 +0200, Xavier Maillard wrote:

La construction du SYSFS_vendor permet de dire que l'on veut
prendre le paramètre vendor du périphérique comme identifiant de
notre clé. Ensuite udev va se charger à chaque fois qu'il le
détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1
(dans le cas d'une seule clé). udev s'occupera également de
supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.

Utiliser les strings "Vendor" et "Product" n'est pas vraiment une idée
géniale pour identifier un périphérique USB: il faut savoir que les
chaines de description sont optionnelles et libres en USB. Ce qui fait
qu'elles sont parfois vide, parfois rempli avec n'importe quoi et il n'est
pas rare qu'elles changent entre 2 releases de firmware. De plus, un
constructeur vend souvent plus d'un périphérique USB, de types
complètement différent.
Il faut utiliser les attributs DeviceClass, DeviceProtocol et
DeviceSubclass (comme défini dans la norme USB) pour repérer les
périphériques génériques (hubs, storages, ...) (voire les
classes/protocoles/sous-classes des interfaces, mais c'est plus compliqué
et plus rare) et utiliser les VendorID, ProductID et revisionID
numériques pour les autres. C'est la seule méthode réellement fiable
d'identification, pour l'USB au moins.

Comment obtenir les attributs DeviceClass, DeviceProtocol et
DeviceSubclass ?

La commande systool utilisée avec l'option -v (Show all attributes with
values) ne donne pas ces paramètres...

Merci de ton aide.
(Je suis en train de faire une petite doc sur udev/hotplug)




--

prends du temps, faut litre la doc, bidouiller, etc...
Codez bourrés, postez déchirés!

Que celui qui à déja séché me jette la premiére biére.

-+- PL in GFA : Attention chute de bières -+-