Re: How to tell whether a struct file is held by a process?

[Pantelis Koukousoulas <pktoss@gmail.com>]

>> > 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