From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Tue, 16 Jun 2015 15:49:43 +0200 Message-ID: <55802977.8060309@suse.com> References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <21887.64856.265751.921367@mariner.uk.xensource.com> <558000E5.9000803@suse.com> <21888.1058.681450.470806@mariner.uk.xensource.com> <5580079D.6070007@suse.com> <21888.3180.937801.173964@mariner.uk.xensource.com> <55801F56.1090906@suse.com> <55802025.2020102@eu.citrix.com> <55802339.40808@suse.com> <558024B3.2060303@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558024B3.2060303@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ian Jackson Cc: Wei Liu , Ian Campbell , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org 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 : syntax to >>>> :: 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