Sie können libudev verwenden oder analysieren Sie udevadm Ausgabe wie von @Ambroz Bizjak vorgeschlagen. Allerdings rate ich davon ab, einen zusätzlichen Prozess hinzuzufügen (stdbuf ) und Sprache (NCD ), nur um die Ausgabe von udevadm zu parsen.
Ein Schritt zwischen einfacher libudev- und Parsing-Ausgabe ist das Modifizieren der udevadm-Quellen. Diese Lösung reduziert die benötigten Ressourcen und überspringt den Parsing-Prozess vollständig. Wenn Sie sich das udev-Paket ansehen, finden Sie die Quellen für udevd und udevadm in udev Verzeichnis.
Dort haben Sie die Hauptroutine in udevadm.c und die Quelle für udevadm monitor in udevadm-monitor.c . Jedes empfangene Ereignis wird über print_device() gedruckt . Hier fügen Sie Ihren Code ein.
Wenn Sie wenig Speicherplatz haben, können Sie nicht benötigten Code für control entfernen , info , settle , test-builtin , test und trigger . Auf meinem System (Ubuntu 12.04) reduziert dies die Größe von udevadm um etwa 75 %.
Leider wird auf der Gadget-Seite kein udev-Ereignis beim Verbinden/Trennen erzeugt, sodass es fast unmöglich ist, diese Ereignisse zu überwachen.
Sie könnten Kernel-Nachrichten (dmesg) überwachen. Es scheint eine dumme Idee zu sein. Oder sehen Sie sich einige Dateien in sysfs an. Vielleicht ist Kernel-Patching der bessere Weg.
Aktualisierung: Ich verstehe nicht, warum diese Antwort viele negative Stimmen erhalten hat.
Vielleicht mischen einige Leute den USB-Host-Teil (der UDEV-Ereignisse beim Einstecken/Ausstecken des Geräts erzeugt) und den USB-Geräte-/Gadget-Teil (der solche Ereignisse nicht erzeugt).
Wenn Ihr Linux-Host als Gadget fungiert (USB-Gerät, das mit einem USB-Host verbunden ist), gibt es keine gute Möglichkeit, Plug-/Unplug-Ereignisse abzufangen.
Beweis:Nachricht von Greg Kroah-Hartman
eine weitere Kopie, wenn der vorherige Link nicht erreichbar ist
Wenn Sie alles in Ihrem einzigen Prozess haben möchten, müssen Sie libudev verwenden, um entweder Ereignisse von udevd zu erhalten oder direkt aus dem Kernel.
Da es ein Problem sein könnte, libudev in Ihrer Anwendung zu verwenden (fehlende Dokumentation?), besteht eine Alternative darin, das Programm udevadm zu verwenden, das Folgendes kann:
- Geräteereignisse melden, nachdem sie von
udevdverarbeitet wurden (udevadm monitor --udev --property), - devive-Ereignisse direkt aus dem Kernel melden (
udevadm monitor --kernel --property) und - Dump udevds Datenbank der aktuellen Geräte (aber nicht die des Kernels!) (
udevadm info --query all --export-db)
udevadm ist Teil des udev-Pakets, sollte aber udevd nicht benötigen wenn Sie es nur verwenden, um Kernel-Ereignisse zu melden. Sie können es verwenden, indem Sie es von Ihrem Prozess spawnen lassen und seine Standardausgabe parsen (aber Sie müssen es über stdbuf -o L starten ).
In jedem Fall wird es wahrscheinlich eine Menge Arbeit sein. Vieles davon habe ich bereits in meiner NCD-Programmiersprache implementiert, einschließlich der Überwachung von USB-Geräten. Vielleicht möchten Sie einen Blick auf NCD werfen; Es ist für viele Konfigurationsaufgaben nützlich und handhabt Hotplugging gut. Dieses NCD-Programm gibt beispielsweise USB-Geräteereignisse auf der Standardausgabe aus:
process main {
sys.watch_usb() watcher;
println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id);
watcher->nextevent();
}
Dadurch wird NCD so etwas drucken (mit einem anfänglichen added Ereignis für ein bereits angeschlossenes USB-Gerät):
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
Sie können NCD auch nur dafür verwenden und dies parsen Standardausgabe - mit der viel einfacher zu arbeiten ist, als direkt mit udevadm herumzuspielen.
Beachten Sie, dass NCD selbst udevadm verwendet , und es macht erfordern, dass udevd läuft; aber warum ist das überhaupt ein problem? (mit etwas Arbeit könnte diese Abhängigkeit entfernt werden)