On Mon, May 4, 2009 at 1:50 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Mon, May 04, 2009 at 01:05:09PM -0700, 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. > > Really? > >> Perfectly USB legal bus sequences hang/kill many devices. > > What types of devices? Bug report pointers somewhere? > The discovery of such failing devices is an on-going process. Remember the issues in early Linux doing device enumeration - it eventually evolved into: do the earliest enumeration as Windows98/XP did it, not the completely legal sequence that the early kernel did it. At work I have a flash drive that hangs is it gets a set interface 0/alt0. There seems to be many quirks for storage devices, hid devices, audio devices that are all working around broken gadgets already in the kernel. >> 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). >> >> 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. > > udev isn't in "control" of anything. It passes all "hey I see a new > device" messages off to modprobe, which then does the device matching > and tries to load a new driver if possible. > > Then the kernel does the real matching and attaching drivers to devices. > Right, and the problem is the kernel uses its own rules for probe order. And if a recently started emulator system wants to grab all devices to at least decide if it wants them (even a kernel module), the kernel will use its in-build policy of how to probe for drivers. >> 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. > > Ick, no. > > You all seem to be spinning downward from what the original > proposal/goal here was: > > - create a new "top level" usb driver and register it with the kernel. > - this driver grabs any devices seen and then can decide if it really > wants to control it. > - if not, hand it back to the kernel with the standard "I can't > control this device" error, and then the standard Linux USB "top > level" driver takes over like today. > This solution is ok. I think though, that qemu would rather have a solution that would just run as a user app, without forcing the install (or user) to build a kernel module to match the particular kernel version and distribution he is currently running. If you are suggesting adding a top level driver to the usb system which user space can control for device (or port) to driver probing even better. > It's really not that complex, please don't make it out to be much more > than is really necessary here. > > Hope this helps, > > greg k-h > -- 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
