From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZaZZ-0002bx-FC for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:17:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZaZV-00077z-Jj for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:17:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZaZV-00077u-EU for qemu-devel@nongnu.org; Wed, 09 Sep 2015 04:17:37 -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 D4D668C1C3 for ; Wed, 9 Sep 2015 08:17:36 +0000 (UTC) Message-ID: <1441786654.14506.35.camel@redhat.com> From: Andrea Bolognani Date: Wed, 09 Sep 2015 10:17:34 +0200 In-Reply-To: <20150908154753.GJ4307@redhat.com> References: <1441718858.14506.1.camel@redhat.com> <20150908143702.GG4307@redhat.com> <1441726482.14506.22.camel@redhat.com> <20150908154753.GJ4307@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Target vs architecture for QEMU binary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org 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? > > 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. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team