Linux usb connect / disconnect event

Question

Hello, I am working on an embedded Linux device with a usb port that uses the g_ether driver for usb networks.

When a USB connector is connected, dmesg output:

g_ether gadget: full configuration configuration # 2: RNDIS

When the USB cable is disconnected, not a single message is written to dmesg.

Using C, how can I listen for connect / disconnect events?

The embedded Linux OS does not have any additional features. The dbus daemon or hotplug helper is not a script. I'm not even sure that would be helpful.

Answer 1

If you need everything in one process, you will have to use libudev to get events from udevd or directly from the kernel.

Seeing that it might be a problem to use libudev in your application (lack of documentation?), An alternative is to use the udevadm program, which can:

• udevd device events after udevd processing ( udevadm monitor --udev --property ),
• udevadm monitor --kernel --property deviation events directly from the kernel ( udevadm monitor --kernel --property ) and
• unload the udevd database of current devices (but not the kernel!) ( udevadm info --query all --export-db )

udevadm is part of the udev package, but should not need udevd if you only use it to report kernel events. You can use it if your process spawns it and parses its standard output (but you have to run it through stdbuf -o L ).

In any case, there will probably be a lot of work. I have already implemented a lot of this in my NCD programming language , including USB device monitoring. You might want to take a look at NCDs; This is useful for many configuration tasks and handles hot plugging well. For example, this NCD program will print USB device events to standard output:

 process main { sys.watch_usb() watcher; println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id); watcher->nextevent(); } 

This will force NCD to print something similar (with an added start event for any USB device that has already been connected):

 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 

You can also use NCD just for this and analyze this standard output - it is much easier to work with it than directly contact udevadm.

Note that NCD itself uses udevadm , and this requires udevd to work; but why is this a problem anyway? (with some work this dependency can be removed)

Answer 2

You can use libudev or do udevadm as @Ambroz Bizjak's suggestion. Although, I advise you not to add an extra process ( stdbuf ) and language ( NCD ), just to parse the udevadm output file.

The step between simple libudev and the syntax expression changes the sources of udevadm. This solution reduces the necessary resources and generally skips the analysis process. When you look at the udev package, you will find the sources for udevd and udevadm in the udev directory.

There, you have the main procedure in udevadm.c and the source of udevadm monitor in udevadm-monitor.c . Each event received will be printed via print_device() . Here you insert your code.

If you are tightly locked in memory, you can remove unnecessary code for control , info , settle , test-builtin , test and trigger . On my system (Ubuntu 12.04) this reduces the size of udevadm by about 75%.

Answer 3

Unfortunately, when connecting / disconnecting, the udev event does not occur on the gadget side, so it is almost impossible to track these events.
You can track kernel messages (dmesg). This seems like a dumb idea. Or look at some files in sysfs. Perhaps the best way is to fix the kernel.

update: I do not understand why this answer received a negative rating.
Perhaps some people mix the part of the USB host (which generates UDEV events when connecting / disconnecting the device) and the part of the USB device / gadget (which does not generate such events)
If your Linux computer works as a gadget (a USB device that is connected to some USB host), then there is no good way to catch on / off events.

Proof: Greg Croah-Hartman post
another copy if the previous link does not work