>> 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. Agreed (unfortunately). Hopefully we will figure this out :) > > 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? Well, in my proposal the program would either have the port grabbed or not. As long as it doesn't release the port, all devices connected there would be assigned to it. There would just be no way to express interest in a "device" (i.e., one or more interfaces). If one needs an interface, it is already possible to claim it through usbfs. Releasing a port would mean the device connected there is reset and reconfigured by the kernel as if it was just plugged in. Such functionality would be more than enough to allow qemu/usbip (even in the multiseat case) to work. What are the specific use-cases that would require claiming a device instead of a port? Remember that if a device is connected, the userspace program can go via a 2-stage discovery process: First find the device through usbfs, take a note of the port it is connected to and claim the port. So I can't yet see what additional value would the ability to claim a device directly (in one step) bring. > >> > 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... Well, I 'm not just "wishing those usecases away". I thought I described what the consequences would be and none of those involved a kernel crash or panic or even a situation where the user would be too confused to know what to do next. I agree that we can't just assume "proper" user behavior, but then again unix has never been in the business of preventing people to shoot themselves in the foot :) (it just tries to limit the consequences - e.g., memory protection). So what if the user (in a corner case) has to explicitly disconnect and reconnect a device to make it work, yet the user connects to the wrong port? Nothing will happen, so they will try again with a different port and in the end they will get it right :) With a proper user interface from the emulation process, this can be even less error-prone. The alternative (current situation) is that you connect a device and try to assign it to qemu. Then you watch said device load its firmware and just hang. Even for relatively experienced users this causes a wtf moment and one that has no way out :( > >> 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. Well, some things like Set-Configuration and Set-interface (i.e., those that people complain about) can presumably be avoided. Thanks, Pantelis -- 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
