Puedes usar libudev o analizar udevadm salida como sugirió @Ambroz Bizjak. Aunque, desaconsejo agregar un proceso adicional (stdbuf ) e idioma (NCD ), solo para analizar la salida de udevadm.
Un paso entre libudev simple y la salida de análisis es modificar las fuentes de udevadm. Esta solución reduce los recursos necesarios y omite el proceso de análisis por completo. Cuando mire el paquete udev, encontrará las fuentes para udevd y udevadm en el udev directorio.
Ahí tienes la rutina principal en udevadm.c y la fuente de udevadm monitor en udevadm-monitor.c . Cada evento recibido se imprimirá a través de print_device() . Aquí es donde inserta su código.
Si tiene poca memoria, puede eliminar el código innecesario para control , info , settle , test-builtin , test y trigger . En mi sistema (Ubuntu 12.04), esto reduce el tamaño de udevadm en aproximadamente un 75 %.
Desafortunadamente, no se produce ningún evento udev en la conexión/desconexión del dispositivo, por lo que es casi imposible monitorear estos eventos.
Puede monitorear los mensajes del kernel (dmesg). Parece ser una idea estúpida. O mire algunos archivos en sysfs. Quizá la mejor forma sea aplicar parches al kernel.
actualización: No entiendo por qué esta respuesta tiene muchos votos negativos.
Tal vez algunas personas mezclen la parte del host USB (que produce eventos UDEV al conectar/desconectar el dispositivo) y la parte del dispositivo/dispositivo USB (que no produce tales eventos)
Si su host de Linux funciona como un dispositivo (dispositivo USB que está conectado a algún host USB), no hay una buena manera de detectar eventos de conexión/desconexión.
Prueba:mensaje de Greg Kroah-Hartman
otra copia si el enlace anterior está caído
Si quiere todo en su proceso único, tendrá que usar libudev para obtener eventos de udevd o directamente desde el kernel.
Al ver que puede ser un problema usar libudev en su aplicación (¿falta de documentación?), una alternativa es usar el programa udevadm, que puede:
- informar eventos del dispositivo después de ser procesados por
udevd(udevadm monitor --udev --property), - informar eventos de devive directamente desde el kernel (
udevadm monitor --kernel --property), y - volcar la base de datos de udevd de los dispositivos actuales (¡pero no los del kernel!) (
udevadm info --query all --export-db)
udevadm es parte del paquete udev, pero no debería necesitar udevd si solo lo usa para informar eventos del kernel. Puede usarlo haciendo que su proceso lo genere y analice su salida estándar (pero tendrá que iniciarlo a través de stdbuf -o L ).
De cualquier manera, probablemente será mucho trabajo. Ya he implementado mucho de esto en mi lenguaje de programación NCD, incluido el monitoreo de dispositivos USB. Es posible que desee echar un vistazo a NCD; es útil para muchas tareas de configuración y maneja bien la conexión en caliente. Por ejemplo, este programa NCD imprimirá los eventos del dispositivo USB en la salida estándar:
process main {
sys.watch_usb() watcher;
println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id);
watcher->nextevent();
}
Esto hará que NCD imprima algo así (con un added inicial evento para cualquier dispositivo USB que ya estaba enchufado):
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
También puede usar NCD solo para esto y analizar this salida estándar, con la que es mucho más fácil trabajar que jugar con udevadm directamente.
Tenga en cuenta que el propio NCD usa udevadm , y lo hace requiere que udevd se esté ejecutando; pero ¿por qué es eso un problema de todos modos? (con algo de trabajo, esta dependencia podría eliminarse)