From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZgaz-0005bl-V7 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 10:43:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZgay-0000M0-MB for qemu-devel@nongnu.org; Wed, 09 Sep 2015 10:43:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZgay-0000Ln-Hh for qemu-devel@nongnu.org; Wed, 09 Sep 2015 10:43:32 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 40CD340C59 for ; Wed, 9 Sep 2015 14:43:32 +0000 (UTC) Date: Wed, 9 Sep 2015 15:43:29 +0100 From: "Daniel P. Berrange" Message-ID: <20150909144329.GP22200@redhat.com> References: <1441718858.14506.1.camel@redhat.com> <20150908143702.GG4307@redhat.com> <1441726482.14506.22.camel@redhat.com> <20150908154753.GJ4307@redhat.com> <1441786654.14506.35.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1441786654.14506.35.camel@redhat.com> Subject: Re: [Qemu-devel] Target vs architecture for QEMU binary Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Bolognani Cc: qemu-devel@nongnu.org On Wed, Sep 09, 2015 at 10:17:34AM +0200, Andrea Bolognani wrote: > On Tue, 2015-09-08 at 16:47 +0100, Daniel P. Berrange wrote: > > > Or we could just query everything that looks like a QEMU > > > binary and then lookup the correct one for the guest based > > > on the query results, couldn't we? Again, assuming such > > > interface even exists. > > > > I'd prefer libvirt to not have a trawl through every QEMU > > binary to do this really. > > AFAIK we're already querying every binary for other stuff > we're interested in, so adding one more query shouldn't > change anything. Or am I missing something? In all the other cases we already know which binary we need to query. We happen to cache the results of querying binaries we find in $PATH, but none of our code has a fixed assumption that we have caps available for every single binary. I don't want such an assumption to get baked into libvirt code, because it will limit our flexibility to change the way we probe / cache capabilities data later, if we have a requirement to always query every binary upfront. > > > I'm not sure they're covering all possible combinations, > > > though. Which is why it would be really nice to be able to > > > ask this stuff to QEMU itself. > > > > So, I think what we need do is to just refactor the > > virQEMUCapsFindBinaryForArch(), to pull out the > > architecture canonocalization out into a separate > > method eg virArch virQEMUCapsCanonicalSystemArch(virArch) > > and then just call it from both places > > Sounds reasonable. Are we sure we have a complete > understanding of the relationship between targets and > architectures, though? For example, I don't see anything > about s390, and the ARM stuff doesn't look like it covers > everything. I just want to make sure we're not doing > anything wrong or missing any possible combination. Yeah, we've just added exceptions on an as-nedeed basis, so we could well need more special cases added Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|