On Thu, Jul 30, 2009 at 10:37, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 29 Jul 2009, Kay Sievers wrote: > >> Yeah, I'm sure. The thing is that the kernel USB code for some weird >> reason returns -ENOENT instead -ENODEV -- hence the misleading error >> string. > > That return code can easily be changed. If we don't confuse anything, I guess that would be better, as it's really about a device not being there, not a file. >> Alan, I suspect (haven't checked) that at the time we get the event >> for the usb_device, the device is not ready to be handled by usbfs >> operations. Is that likely? And if, any idea how, and until which >> point, to delay the usb_device uevent, in which we hook in to do the >> usbfs actions from userspace? > > There are two aspects we have to consider: usbfs device nodes > (/dev/bus/usb/*/*) and usbfs file nodes (/proc/bus/usb/*/*). The > device nodes are created by udev whereas the file nodes are created by > the kernel (if CONFIG_USB_DEVICEFS is enabled). Nowadays most people > use the device nodes, but embedded systems without udev may want to > rely on the file nodes. > > With the device nodes, the problem is this: usbdev_open() looks up > dev_t values by calling bus_find_device(). But devices are added to > the bus's list by bus_attach_device(), which isn't called until after > the KOBJ_ADD uevent is sent. Hence there's a window after the uevent > is issued and before the device can be looked up on the bus. That's > probably what's happening here. Yeah, that sounds likely. > Interchanging bus_attach_device() and kobject_uevent() in device_add() > would solve this problem, but it would introduce other problems. In > particular, if a probe routine registered a child device then the > child's uevent would be sent before the parent's! Right, we can not do that. > You know, the real problem may lie in bus_attach_device(). If probing > fails then it doesn't add the device to the bus -- and it doesn't even > return an error code when this happens. One can argue that the device > should _always_ be added to the bus, regardless of whether a suitable > driver can be found. If you accept that argument then linking the > device into the bus's list should be moved up into bus_add_device(), > which is called before the uevent. Indeed, each of those two routines > has a comment in the kerneldoc saying "Add the device to its bus's list > of devices." They can't both be right! That sounds like the right thing. We create all the links which indicate a membership at the bus, so we should put it to the bus at the same time. > There's also a problem with usbfs file nodes. The file nodes are > created by the device's probe routine. So again, if the uevent comes > before probing then it will come before the file nodes exist. I > suppose we could create the file nodes earlier, before the device is > registered, but is this really a good idea? Oh, I don't think we really need to care about the proc files and the uevent timing. Users of the proc files usually don't hook into the events but poll the devices file. The event timing and the proc files have been broken since the first day, and you always needed to loop until the proc file showed up. Also, we expect to get a devtmpfs which will create the /dev/bus/usb/ nodes from inside the kernel, so the proc things can be ignored for almost all use cases after that. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
