>> I 'm imagining this driver having attributes in sysfs where a userspace >> program can inform it about what ports the program wishes to grab. > > Note that "ports" can be renumbered across reboots, so be careful about > that. Yes, I 've bumped into that once already. It is not a very big deal if you don't reboot very often, but I guess I should see if there is any way to have somewhat persistent naming for ports based on their physical location. I doubt this is implementable with current technology though. (At least in a straightforward way) > >> What means would the kernel then use to inform userspace that a device >> was connected in one of the grabbed ports? > > kevent like it does today? Why would you need anything different? kevent should be fine I guess. >> I have looked, the problem we are discussing is relevant for usb-ip >> too. E.g., see this mail: >> >> http://www.isely.net/pipermail/pvrusb2/2007-July/001573.html >> >> This is from a user that tried to pass-through his hauppauge pvr >> to another machine through usb-ip and had it "just not work". >> The driver author explains the reason of the problem. >> >> Note that this is the same with almost all devices that use the FX2 >> chip which is very common and probably with the ZeroCD devices >> too (and who knows what else). > > That poster seems to think this is a major problem, I don't think it is > at all. Just bind the "final" device through usb-ip, the "firmware" > devices can easily be ignored as they have a different device id. > >> The fact that usb-ip uses a "stub-driver" for its backend doesn't >> provide any advantage in this case because it is a per-interface >> driver AFAICT, i.e., not that much different from usbfs. > > Yeah, it would be nice to convert it to be a "real" generic USB driver. > That would be the proper solution for it. I 'm more of the opinion that we need a generic "vhci" driver that everyone interested (Xen PvUSB, Virtio usb, usb-ip) can use. Then, we have various "transports" (one for each of the above) and finally we drop the backend "stub drivers" alltogether. Instead, we have a small generic driver that arbitrates ports between kernel and userspace and use usbfs for the rest. If usbfs is broken in any way, it should be fixed since it is useful for several people, not just qemu/usbip/xen/whoever. That would probably be good even for usbip, since its components can be reviewed / merged independently without being blocked by the current file descriptor leaking and protocol-needs-a-rewrite issues. 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
