• # C'est possible

    Posté par (site web personnel) . En réponse au message Créer udev rule pour périphérique USB avec plusieurs ports virtuels. Évalué à 4.

    Je ne suis pas certain de ce que tu entends par « je ne crée qu'un port équivalent au port config ». J'imagine que ça peut signifier créer un lien symbolique sous /dev pour ce port en question ?

    Quoi qu'il en soit, c'est une problématique très classique dans la gestion des modems et des équipements type liaison série. Dans le premier cas, il y a des ports de gestion/commandes AT, des ports de données, etc. La règle (udev) numéro 1, c'est de regarder ce que font les autres règles (/lib/udev/rules.d/*.rules me dépanne 75 % du temps).

    Si tu cherches principalement à peupler /dev, tu peux discriminer entre les ports via le numéro d'interface. Exemple :

    SUBSYSTEMS=="usb", ENV{.LOCAL_ifNum}="$attr{bInterfaceNumber}"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ACTION=="add", \
 ATTRS{idVendor}=="<foo id>", ATTRS{idProduct}=="<bar id>", ATTRS{product}=="Foo Bar Config port", \
 ENV{.LOCAL_ifNum}=="00", SYMLINK+="foo-bar-config%s{devpath}", GROUP="if-you-need-it", MODE="0666"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ACTION=="add", \
 ATTRS{idVendor}=="<foo id>", ATTRS{idProduct}=="<bar id>", ATTRS{product}=="Foo Bar Data port", \
 ENV{.LOCAL_ifNum}=="01", SYMLINK+="foo-bar-data%s{devpath}", GROUP="if-you-need-it", MODE="0666"

    Après bien sûr, on peut faire des choses plus avancées :

    • ajouter des métadonnées via l'environnement pour faire des recherches faciles depuis udevadm ou les API udev : ENV{VARIABLE1}="valeur1" (on peut en mettre plusieurs).
    • taguer un port (ou plusieurs) avec systemd et ajouter une référence vers une unité systemd pour qu'elle donne lieu au lancement automatique d'une unité : TAG+="systemd", ENV{SYSTEMD_WANTS}="unit-for-foo-bar@foo-bar-config-%s{devpath}.service". Une des subtilités ici est de savoir si on veut une unité par port ou une par device. Dans le second cas, une fois les liens symboliques en place, c'est plutôt facile de passer d'un port à un autre... C'est ce que j'ai privilégié sur un projet client, cela signifie une seule unité à surveiller, et pas d'interaction entre deux unités « sœurs » à gérer.

    Attention à la gestion du hotplug : en fonction du matériel, on peut avoir besoin d'accepter d'autres valeurs qu'add pour ACTION (par exemple add|change|move|bind, vu pour des modems).

    Debian Consultant @ DEBAMAX