On Mon, May 4, 2009 at 11:35 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 4 May 2009, Pantelis Koukousoulas wrote: > >> Anyway, I 'd prefer to have the possibility to assign only a >> few ports/hubs to userspace and keep the rest functioning >> normally, as long as this doesn't cause significant trouble elsewhere. > > I can understand that; it makes sense. > >> So, the first step in the process would be a userspace >> program claiming one or more ports/hubs or a wildcard >> "everything" from the kernel, right? > > Yes. It's not obvious what would be a good API for doing this. > 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). 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. Regards, Steve -- 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
