On Tue, May 05, 2009 at 06:25:42AM +0300, Pantelis Koukousoulas wrote: > >> 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? Yes. > 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? If you want to use that criteria, sure, go ahead. > 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. > 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? > > 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 :). A few years ago, I was told that it was such a thing. Also, usbfs met their requirements at the time, so they didn't really need to do any other work. > 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). Probably. > If it was due to licensing only, that would be great news, because > I just don't have this problem, hehe :) It would be nice to get everyone to agree on a common solution, I agree. > > 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). 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. good luck, greg k-h -- 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
