2011-08-19 14 views
8

Hola, estoy trabajando en un dispositivo linux incorporado con un puerto usb que usa el controlador g_ether para la conexión de red usb.evento usb connect/disconnect de linux

Cuando el conector USB se conecta la salida de dmesg es:

g_ether aparato: config toda velocidad # 2: RNDIS

Cuando el cable USB está desconectado ningún mensaje se escribe en dmesg.

Usando C ¿cómo puedo escuchar los eventos de conexión/desconexión?

El sistema operativo Linux incorporado no tiene ningún extra. No hay script dbus daemon o hotplug helper. Ni siquiera estoy seguro de si esto hubiera sido útil.

+0

¿Se tienen al menos udev? – Keith

+0

Desafortunadamente no lo hago. ¿Es imposible escuchar este tipo de evento en modo de usuario sin udev? –

+0

Creo que esa es la mejor manera de obtener eventos kernel. Una alternativa es el usbd anterior en [linux-hotplug] (http://linux-hotplug.sourceforge.net/). – Keith

Respuesta

4

Si quieres todo en tu proceso individual, tendrás que usar libudev para obtener eventos del udevd o directamente del kernel.

Viendo que podría ser un problema para usar libudev en su aplicación (? Falta de documentación), una alternativa es utilizar el programa udevadm, lo que puede:

  • eventos del dispositivo informe después de haber sido procesado por udevd (udevadm monitor --udev --property),
  • informe de eventos devive directamente desde el núcleo (udevadm monitor --kernel --property), y la base de datos
  • volcado de udevd de los dispositivos actuales (pero no los del núcleo!) (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 deberá iniciarlo a través del stdbuf-o L).

De cualquier manera, probablemente será mucho trabajo. Ya he implementado mucho de esto en mi NCD programming language, incluida la supervisión 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 a 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 algo de impresión NCD así (con un added evento inicial 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 esta salida estándar, que es mucho más fácil de trabajar que jugar directamente con udevadm.

Tenga en cuenta que el propio NCD usa udevadm, y hace requiere udevd para ejecutarse; pero ¿por qué es eso un problema? (con algún trabajo, esta dependencia podría eliminarse)

2

Puede usar libudev o analizar el resultado udevadm como @Ambroz Bizjak sugirió.Aunque, desaconsejo agregar un proceso adicional (stdbuf) e idioma (NCD), solo para analizar la salida de udevadm.

Un paso entre plain libudev y la salida de análisis está modificando las fuentes de udevadm. Esta solución reduce los recursos necesarios y omite por completo el proceso de análisis. Cuando mira el paquete udev, encontrará las fuentes para udevd y udevadm en el directorio udev.

Ahí tienes la rutina principal en udevadm.c y la fuente udevadm monitor en udevadm-monitor.c. Cada evento recibido se imprimirá a través del print_device(). Aquí es donde insertas tu código.

Si usted es apretado en la memoria, puede despojarse de código que no sean necesarios 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%.

-3

Lamentablemente, no se produce ningún evento de udev al conectar/desconectar, por lo que es casi imposible supervisar estos eventos.
Puede supervisar los mensajes del kernel (parece ser una idea loca). La mejor manera posible es modificar kernel.

actualización: No entiendo por qué esta respuesta obtuvo calificación negativa.
Tal vez algunas personas mezclan la parte del host USB (que produce eventos UDEV en el dispositivo conectar/desconectar) y la parte del dispositivo/gadget USB (que no produce dichos eventos)
Entonces, si su computadora Linux funciona como un dispositivo (dispositivo USB que está conectado a un host USB) no hay una buena manera de atrapar los eventos de conectar/desconectar.

Prueba: message by Greg Kroah-Hartman

+0

Fuentes? ¿Puedes explicar tu razonamiento y dónde comenzar con la implementación? – bschlueter

+0

Edité mi respuesta para una explicación más detallada. Si toma la decisión de ver los mensajes del kernel, puede ver cómo proceder/proc/kmsg en fuentes de dmesg o puede usar algún programa de supervisión de archivos de registro ADSL syslog daemon como swatch. – edo1

Cuestiones relacionadas