Hello I am working on an embedded linux device with a usb port that uses the g_ether driver for usb networking.
When the usb plug is connected the dmesg output is:
Unfortunately, there is no udev event produced on connect/disconnect on gadget side, so it is almost to impossible to monitor these events.
You could monitor kernel messages (dmesg). It seems to be stupid idea. Or watch some files in sysfs. Possible better way is kernel patching.
update: I do not understand why this answer got negative rating.
Maybe some people mix USB host part (which produces UDEV events on device plug/unplug) and USB device/gadget part (which doesn't produce such events)
If your linux computer works as a gadget (USB device which is connected to some USB host) there is no good way to catch plug/unplug events.
Proof: message by Greg Kroah-Hartman
another copy if previous link is down
You can use libudev or parse udevadm
output as @Ambroz Bizjak suggested. Although, I advise against adding an additional process (stdbuf
) and language (NCD
), just to parse udevadm's output.
A step between plain libudev and parsing output is modifying the udevadm sources. This solution reduces the needed resources and skips the parsing process altogether. 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 routine in udevadm.c
and the source for udevadm monitor
in udevadm-monitor.c
. Every event received will be printed through print_device()
. This is where you insert your code.
If you're tight on memory, you can strip off unneeded 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%.
If you want everything in your single process, you'll have to use libudev to either 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
(udevadm monitor --udev --property
),udevadm monitor --kernel --property
), andudevadm info --query all --export-db
)udevadm
is part of the udev package, but shouldn't need udevd
if you only use it to report kernel events. You can use it by having your process spawn it and parse its standard output (but you'll have to launch it via stdbuf -o L
).
Either way, it'll probably be a lot of work. I've already implemented a lot of this in my NCD programming language, including monitoring of USB devices. You might want to take a look at NCD; it's useful for a lot of configuration tasks, and handles hotplugging 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 make NCD print something like that (with an initial added
event for any USB device that was already plugged in):
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 parse this standard output - which is much easier to work with than messing with udevadm directly.
Note that NCD itself uses udevadm
, and it does require udevd to be running; but why is that a problem anyway? (with some work this dependency could be removed)