Catching up on an old thread: From: "Thomas Sailer" <[EMAIL PROTECTED]> > Duncan Sands wrote: > > > races with disconnect. In usb.c there is the usb_disconnect > > function which first calls driver->disconnect, then only later > > Ah ok, you're concerned about the driver ioctl getting called > via usbdevfs. The proc_ioctl interface wasn't added by me, > so I don't know the original intention (Greg K-H? David Brownell?)
It gives a way to talk to drivers that may not appear on the filesystem otherwise, as well as to look at the "physical" layer of the driver stack. And as Thomas noted: > You can probably fairly easily guard against it, since you most likely > have to have a function that takes the usb_device * and finds the > corresponding driver internal state. Duncan's point was accurate: that locking is not an issue with drivers accessed through char or block special files. On the other hand, those would use the "regular" ioctl route, so it'd not normally be an issue. (Except for stuff like "what's your major/minor?", which has been needed to find what /dev node matches a given new USB device.) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
