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. There also has to be a way for the program to release a device when it decides it isn't interested in that device any more. (The release would need to tell the kernel whether to reconfigure the device or to leave it as is.) What then should happen if the device is unplugged and something else is plugged into that port -- should the program somehow retain ownership of the port while giving up ownership of the device? > > What happens if a device the program isn't interested in gets plugged > > into one of the ports it has claimed? Or what happens if a device the > > program _is_ interested in gets plugged into an unclaimed port? To > > handle these situations, isn't it better to do the claiming based on > > the device ID rather than on the port? > > > > I 'm assuming those cases just won't happen. My claim is that it is > possible for the user interface of the userspace program > (e.g., qemu / kvm) to ensure this. I doubt that. It's hopeless to assume that undesired cases "just won't happen" -- especially if they involve making assumptions about the user's behavior! People do all sorts of strange things... > The alternative, assigning all devices to qemu, would > mean that either the kernel would touch the device > in between the disconnect/reconnect cycle thus > breaking it, or the kernel now has to ask qemu > for every single new device if it should be claimed > or not. There is no way to avoid having the kernel "touch" a device when it is reset or reconnected. 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
