>> 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. > > Ick, no. > > You all seem to be spinning downward from what the original > proposal/goal here was: > > - create a new "top level" usb driver and register it with the kernel. > - this driver grabs any devices seen and then can decide if it really > wants to control it. > - if not, hand it back to the kernel with the standard "I can't > control this device" error, and then the standard Linux USB "top > level" driver takes over like today. > > It's really not that complex, please don't make it out to be much more > than is really necessary here. I like this proposal, it seems to be pretty much the same with what I have in mind. So the new top-level driver would just always be probed before usb_generic, right? What criteria would it use to decide if it wants the device or not? Is it ok to use the port the device is connected to? I 'm imagining this driver having attributes in sysfs where a userspace program can inform it about what ports the program wishes to grab. What means would the kernel then use to inform userspace that a device was connected in one of the grabbed ports? > > And yes, this will require a in-kernel Linux driver, which is why vmware > has not done this, because of the licensing issues involved that they > seem to want to ignore/avoid/piss on. > > But kvm/qemu can do this, so it shouldn't be an issue. Was it really because of the licensing issues? I don't see how this code would be directly related to vmware and they have released GPL code before (e.g., VMI, the fact that this turned out to be somewhat of a fiasco is irrelevant :). My impression was that nothing was implemented because there wasn't an agreed upon solution within the allocated time frame (so probably the employee just moved on to different things). If it was due to licensing only, that would be great news, because I just don't have this problem, hehe :) > > Also, you might want to look into the usb-ip interface, that might be > sufficient for what you are doing, I know it is what a lot of KVM > instances use today. 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). 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. Regards, 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
