>> Wouldn't that mean that the kernel's hotplug >> subsystem would now have to wait approval from >> userspace on whether to go on >> its way configuring a device or not? > > That's right, it would -- provided a program had registered its > interest in vetting all new devices. If no programs were interested > then everything would proceed normally. I 'm still a bit uneasy with userspace taking over my entire usb hotplug subsystem and thus potentially breaking everything. I suppose it is not that bad because this wouldn't happen at boot time, but only after a user has explicitly loaded such an application. That means critical stuff like a usb disk with the rootfs are unlikely to break due to this functionality (but then again, is that true accounting for resets needed for error recovery in usb-storage?) 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. 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? > Is what I described really any different from simply claiming all the > unoccupied ports on all hubs? AFAICT no, it is not different, I 'd just like to also have a little finer control if possible. >> Claiming a port / port range could be implemented by having a filter >> in the kernel >> that decides whether to bind usb_generic or usb_alternative/usb_userspace based >> on the bus.port address (thus no need to set configuration or read descriptors). > > There's no need to go into such low-level details at this point. We're > still discussing the high-level overview. Agreed, will try to stay high-level from now on. >> The userspace program just informs the kernel (e.g., through sysfs) >> about the ports/hubs it wants to claim. >> There is no kernel<->userspace interaction during hotplug, >> communication stays one-way only. > > It can't be totally one way. Otherwise the kernel wouldn't be able to > inform the program when a new device was plugged into one of the ports. Well, the "one way" was kernel->userspace, so I didn't really get that :) My point was that by requiring the userspace to claim what ports it wants for itself in advance and by using ports instead of VID:PID etc, the kernel doesn't have to be in the (evil / frowned upon) "wait for userspace" business, during the actual hotplug path. > > 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. Also, if a user has a device that is by definition 'difficult' (e.g., renumeration, ZeroCD, assuming a specific init order etc) it is better to ask this user to jump through a few easy hoops to make this device work, rather than having it not work no matter what. To get difficult devices to work (at least give them a fair chance), we need to be able to have persistence across reconnects. I.e., I connect my pvr to a pre-grabbed port and qemu gets a connect, disconnect and a second connect and nobody else messes with the device in between. I can't see how this can be done if we introduce VID:PID into the picture. OTOH, selecting by VID:PID is not hard to do on top of this infrastructure. It just works like this: Step 1: Qemu starts with the device already connected (so it can easily find it by VID:PID by walking usbfs). It takes a note regarding which port this device is connected to. Step 2: Qemu claims this port for itself. If the device is really buggy, it can also ask the user to disconnect the device, (even also powercycle it to remove the current firmware) and reconnect to the same slot. Otherwise, just a reset will probably do, so the user doesn't have to do anything explicitly. Step 3: Qemu is now fully in charge of the device and things will stay this way, unless it explicitly gives back its grab, or someone kills it. Now, in case both the device is broken *and* the user by mistake reconnects to a different port, then no big deal imho. The device will appear to be hotplugged to the host instead of the guest, so the user most likely will keep switching ports until they get the right one :) The point is that this process does not require any advanced knowledge from the user (or even critical thinking), just "brute force" in the worst case :) 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. Qemu would need access to VID:PID to decide, thus again the device could be potentially broken :) Also, this could be quite confusing for e.g., multiseat: "Why has my hotplug become slow? Are you running qemu again?" and in addition introduces this kernel<->userspace feedback loop with deadlock potential. (kernel waiting for qemu/kvm but also holding locks that kvm needs released to be able to make progress). Cheers, 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
