Messages in this thread |  | | | Date | Fri, 22 May 2009 19:23:04 +0300 | | Subject | Re: How to tell whether a struct file is held by a process? | | From | Pantelis Koukousoulas <> |
| |
>> > The second part can be solved (among cooperating processes) by use of >> > port-lock files, with no kernel involvement. The first part does >> > require a kernel interface of some sort, but it wouldn't have to be >> > complicated. The mere fact that a port-lock file was open could be >> > enough to prevent automatic configuration, probing, and binding. >> >> Given the layout of devices can change fairly arbitarily would the >> ability to claim specific device identifiers via libusb do the job any >> better. >> >> ie would it be better to expose an interface via libusb that was >> essentially >> >> reserve_for_userspace(vendorid, devid); > > That's a good question. I'll defer to the interested parties. > Kyle and Pantelis, what do you think?
When a device needs a reset, it typically comes back with a different VID:PID. So e.g., qemu would have to know both of those, while in the case where we bind to ports it doesn't have to know either. (This is good imho since the device may only have a windows driver and we save the user from some research/experimentation).
I do understand that VID:PID solves the problem with port numbers changing though, but I think in the end using ports is still easier for the user with some effort from the virtualization program implementor.
Note though, I assume that there is / will be a way to reliably predict the port number (at least roughly) given a physical port location. E.g., if I plugged a device to my front left usb connector and it got port number X, it should be possible to predict what the port number will be if I reconnect the same device to the same connector. (This doesn't have to hold across reboots).
Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |