[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/16/2015 03:29 PM, George Dunlap wrote:
On 06/16/2015 02:23 PM, Juergen Gross wrote:
On 06/16/2015 03:09 PM, George Dunlap wrote:
On 06/16/2015 02:06 PM, Juergen Gross wrote:
On 06/16/2015 01:45 PM, Ian Jackson wrote:
Juergen Gross writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb
API"):
On 06/16/2015 01:10 PM, Ian Jackson wrote:
AIUI some devices have serial numbers, which means you can
distinguish
them ?
Yes, they have. The question is whether those are different on
multiple
instances? With "lsusb" I've found a device with serial number
0123456789ABCD. Do you really believe I'm just lucky owning the one
with
such a nice serial number? ;-)
Heh. I think, though, that this suggests that if the user has devices
whose serial numbers are actually different, they should be able to
specify a device by vid/pid/serial.
I think you are right.
The next question: should this be part of libxl or qemu? It should be
possible to extend the qemu <vendorId>:<productId> syntax to
<vendorId>:<productId>:<serial> without too much effort, as libusb
includes some support to obtain the serial number.
It doesn't really matter what qemu or pvusb can do, as long as libxl can
convert what it has into something that they can use. So if libxl is
given vid, pid, and serial (remember, this will be a struct, not a
string), it can look in sysfs and find the bus:addr (which is unique at
any given time) and hand it to qemu (or the bus-port in the case of
pvusb).
Hmm, I'd rather have it all in one place. Putting it in qemu would
enable us to handle hotplug as well. A USB device assigned via it's
serial to a domU could be automatically passed through by qemu when
showing up. This isn't possible today, but we wouldn't have to change
libxl again for supporting it, only qemu would have to be adapted.
Look, we're talking here about the libxl interface. Ian thinks that *at
the libxl layer* we need to be able to specify all these things. It
doesn't matter at this point whether qemu can also do it or not.
When I'm adding new functionality (and this is the case here) I always
try to add it at the level where it should be. qemu already is capable
of finding a USB device by various means and can be extended easily to
support our needs. And please remember, for writing the pvusb backend
I'm already doing changes to qemu.
So why should we add the same functionality to libxl by reading sysfs
instead of letting it do qemu via libusb? And what about BSD? Letting
qemu find the device would avoid two variants in libxl.
In the future, if we actually implement the "automatically grab this
device when it shows up" functionality, then yes, having it in qemu
rather than having a libxl daemon sit around and watch for those things,
might be handy. But we can cross that bridge when we come to it.
I would agree if the efforts in libxl would be much smaller than in
qemu. But if the efforts are comparable I'd rather do it in the
component which will make such an enhancement easier.
Just my $0.02
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
