Vous pouvez utiliser libudev ou parser udevadm sortie comme suggéré par @Ambroz Bizjak. Cependant, je déconseille d'ajouter un processus supplémentaire (stdbuf ) et la langue (NCD ), juste pour analyser la sortie d'udevadm.
Une étape entre libudev simple et la sortie d'analyse modifie les sources udevadm. Cette solution réduit les ressources nécessaires et ignore complètement le processus d'analyse. Lorsque vous regardez le paquet udev, vous trouverez les sources pour udevd et udevadm dans le udev répertoire.
Là, vous avez la routine principale en udevadm.c et la source de udevadm monitor en udevadm-monitor.c . Chaque événement reçu sera imprimé via print_device() . C'est ici que vous insérez votre code.
Si vous manquez de mémoire, vous pouvez supprimer le code inutile pour control , info , settle , test-builtin , test et trigger . Sur mon système (Ubuntu 12.04), cela réduit la taille d'udevadm d'environ 75 %.
Malheureusement, aucun événement udev n'est produit lors de la connexion/déconnexion côté gadget, il est donc presque impossible de surveiller ces événements.
Vous pouvez surveiller les messages du noyau (dmesg). Cela semble être une idée stupide. Ou regardez certains fichiers dans sysfs. Peut-être que le meilleur moyen est de corriger le noyau.
mise à jour : Je ne comprends pas pourquoi cette réponse a reçu de nombreux votes négatifs.
Peut-être que certaines personnes mélangent la partie hôte USB (qui produit des événements UDEV lors de la connexion/déconnexion de l'appareil) et la partie périphérique/gadget USB (qui ne produit pas de tels événements)
Si votre hôte Linux fonctionne comme un gadget (périphérique USB connecté à un hôte USB), il n'y a pas de bon moyen d'attraper les événements de connexion/déconnexion.
Preuve :message de Greg Kroah-Hartman
une autre copie si le lien précédent est en panne
Si vous voulez tout dans votre processus unique, vous devrez utiliser libudev soit pour obtenir des événements de udevd ou directement depuis le noyau.
Voyant qu'il peut être problématique d'utiliser libudev dans votre application (manque de documentation ?), une alternative est d'utiliser le programme udevadm, qui peut :
- signaler les événements de l'appareil après avoir été traités par
udevd(udevadm monitor --udev --property), - signaler les événements devive directement depuis le noyau (
udevadm monitor --kernel --property), et - vider la base de données des périphériques actuels d'udevd (mais pas celle du noyau !) (
udevadm info --query all --export-db)
udevadm fait partie du paquet udev, mais ne devrait pas avoir besoin de udevd si vous ne l'utilisez que pour signaler les événements du noyau. Vous pouvez l'utiliser en demandant à votre processus de le générer et d'analyser sa sortie standard (mais vous devrez le lancer via stdbuf -o L ).
Dans tous les cas, ce sera probablement beaucoup de travail. J'ai déjà implémenté beaucoup de cela dans mon langage de programmation NCD, y compris la surveillance des périphériques USB. Vous voudrez peut-être jeter un œil à NCD; il est utile pour de nombreuses tâches de configuration et gère bien le branchement à chaud. Par exemple, ce programme NCD imprimera les événements du périphérique USB sur la sortie standard :
process main {
sys.watch_usb() watcher;
println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id);
watcher->nextevent();
}
Cela fera imprimer NCD quelque chose comme ça (avec un added initial événement pour tout périphérique USB déjà branché):
added /dev/bus/usb/002/045 0409:0059
added /dev/bus/usb/002/046 046d:c313
added /dev/bus/usb/002/047 046d:c03e
added /dev/bus/usb/002/048 0557:2008
removed /dev/bus/usb/002/048 0557:2008
Vous pouvez également utiliser NCD juste pour cela, et analyser ceci sortie standard - avec laquelle il est beaucoup plus facile de travailler que de jouer directement avec udevadm.
Notez que NCD lui-même utilise udevadm , et il fait exiger qu'udevd soit en cours d'exécution ; mais pourquoi est-ce un problème de toute façon? (avec quelques travaux, cette dépendance pourrait être supprimée)