Hello, Greg. Thanks for the quick reply, and for all your contributions to Linux. On Fri, Sep 11, 2015 at 6:01 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > Can't you wait for libudev to notify your application when the usb > device is attached? That should happen after the normal rules are run. > Have you tried that? I have not tried using a udev_monitor but I do believe it would work. I used it indirectly via libusb and that seemed to work. However, using a udev_monitor would impose an unwelcome constraint, which is the requirement to start monitoring for new devices before the device is plugged into the computer. This complicates the scenario I described in my first email where one program might tell a device to go into bootloader/firmware upgrade mode (which entails disconnecting from USB and re-enumerating), and then another program starts and waits for the bootloader to be available. I wrote about this in point #4 of my first email (quoted below). For future versions of Linux, I would suggest adding a sysfs attribute that changes from "0" to "1" when the rules are fully applied. In the meantime, I will think of a workaround. I'll probably open the devnode file and close it quickly as a test to see if it can be opened, and exclude devices from consideration if that test does not pass. I'll be careful to only do this for devices that I am actually interested in opening, since opening that file can have side effects. If you have better suggestions or know about some way to tell if the udev rules are fully applied, I would be happy to hear it. Thanks again! --David On Fri, Sep 11, 2015 at 4:54 PM, David Grayson <davidegrayson@xxxxxxxxx> wrote: > 4) After a libusb context is created, it looks like libusb detects > changes in the set of USB devices by calling > udev_monitor_receive_device(). The documentation of > udev_monitor_new_from_netlink() says: > >> The "udev" events are sent out after udev has finished >> its event processing, all rules have been processed, >> and needed device nodes are created. > > Unfortunately, using a udev_monitor (or a libusb context) will make my > code more complicated, because there will be a need to start the > monitor and keep it around while we are waiting for the new USB device > to connect. It is simpler if I can just ask the system for a list of > all the USB devices and filter out the ones that are not fully set up > yet, without needing to store any context data, or have global > variables, or have a file handle open to the monitor. > > Also, if I use the udev_monitor (or a libusb context), I will need to > guarantee that this monitor is started well before the device is > plugged in; if the device is plugged in a little bit before the > monitor is started, then I assume I wouldn't receive an event for the > new device, so I cannot be sure that it is ready to be used. This > prohibits the useful scenario where process A tells the device to > disconnect from USB (e.g. to go into bootloader mode and appear as a > new USB device), and then we start process B which actually waits for > the new device to appear and then communicates with it. By the time > process B starts, the new USB device may or may not be detected by the > system, so it is too late to start monitoring for it. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
