On Mon, 4 May 2009, Steve Calfee wrote: > As I see it this is the problem. > > We already have a good user space solution for handling driver loading > and handling devices -- udev. > > The problem is that we have another scheme for allocating drivers to > devices via driver probe routines. When a new device is discovered the > kernel tries to allocate devices to drivers by a first registered gets > first claim on a device. This is done independently of udev. Having > this kernel based method of device to driver mapping makes sense if > there is no udev and a module is already loaded -- known devices get > allocated to drivers. > > The conflict is painful with the many broken (Windows tested only) > devices. Perfectly USB legal bus sequences hang/kill many devices. If > an emulator system (qemu, vmware,...) has an OS driver that knows > exactly how to coddle the broken device, there is currently no known > way to not have the kernel NOT break the device (doing perfectly legal > USB transfers). Are broken devices really the issue here? Sure, it would be nice to be able to prevent kernel drivers from sending these devices requests they can't handle. But I think there may be more to it than just that. > The only solution I see is to have the USB probing stuff be modal - > either the kernel is in control of everything or udev is. I hate modal > interfaces, it is a pain to determine which mode a system is in, > double the debug issues etc, but I see no alternative for the > emulation, remote USB (usb-ip) problems. > > When udev is in charge it should handle driver installation and device > probing. When the kernel is in charge udev can do as it does now, but > the kernel will handle probing. This allows embedded systems and boot > time device handling to go on as now. > > Ideally, multiple (root level emulator created) udev scripts could > simultaneously handle multiple "owners" of devices, both locally and > (multiple) virtual operating systems. Why does udev have to get involved? It doesn't know what other programs (emulators etc.) might be running at any given time. Alan Stern -- 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
