From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlIt6-0001S3-OU for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:59:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlIt5-0000pz-G6 for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:59:52 -0400 Received: from david.siemens.de ([192.35.17.14]:28457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlIt5-0000pp-2i for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:59:51 -0400 Message-ID: <4E2D4CA1.1080504@siemens.com> Date: Mon, 25 Jul 2011 12:59:45 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E2AA4AD.2080608@web.de> <20110725094156.GD21852@amd.home.annexia.org> <4E2D465D.7030502@siemens.com> <20110725104542.GR2532@amd.home.annexia.org> In-Reply-To: <20110725104542.GR2532@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RESEND][PATCH v3] Generalize -machine command line option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Anthony PERARD , Ian Campbell , Anthony Liguori , qemu-devel On 2011-07-25 12:45, Richard W.M. Jones wrote: > On Mon, Jul 25, 2011 at 12:33:01PM +0200, Jan Kiszka wrote: >> On 2011-07-25 11:41, Richard W.M. Jones wrote: >>> On Sat, Jul 23, 2011 at 12:38:37PM +0200, Jan Kiszka wrote: >>>> From: Jan Kiszka >>>> >>>> -machine somehow suggests that it selects the machine, but it doesn't. >>>> Fix that before this command is set in stone. >>>> >>>> Actually, -machine should supersede -M and allow to introduce arbitrary >>>> per-machine options to the command line. That will change the internal >>>> realization again, but we will be able to keep the user interface >>>> stable. >>> >>> This breaks libguestfs which was doing: >>> >>> qemu -machine accel=kvm:tcg ... >>> >>> We are not passing any -M option at all. We don't particularly care >>> about the machine type since we're not that performance sensitive and >>> we don't need to serialize the machine state. >>> >>> I have checked, and this works: >>> >>> qemu -machine pc,accel=kvm:tcg ... >>> >>> "pc" is the default, right? What about for other architectures? >> >> Yes, pc is the right default. Other arch have other defaults. > > So what you're saying is we have to parse qemu -machine \? output by > looking for the string '(default)'? eg: > > $ ./arm-softmmu/qemu-system-arm -machine \?|fgrep '(default)' > integratorcp ARM Integrator/CP (ARM926EJ-S) (default) > > $ ./i386-softmmu/qemu -machine \?|fgrep '(default)' > pc-0.14 Standard PC (default) I understand, this is clumsy. Will see if we can do better. > >>> Please add qemu capabilities, so we can reasonably detect what an >>> unknown qemu binary supports and so we don't need to do endless >>> parsing of the -help output and guesswork. >> >> This syntax was not yet released (but will be with 0.15, so I was >> pushing this). Therefore, nothing was "officially" broken by this patch. >> >> I'm sorry if you may have released any libguestfs with the transient >> syntax, but my patches were waiting quite a while for being merged since >> the introduction of -machine. > > That's an excuse, not a practical solution. We have to be able to > work with any qemu. eg. the qemu in current Fedora Rawhide which > supports only -machine accel=, or qemu in other distros which are also > branched from arbitrary git releases, or qemu that people compile > themselves. In principle, this is first of all a Rawhide problem. Upstream really can't babysit every distro doing crazy things with arbitrary devel snapshots. These patches were public, and the maintainers had a fair chance to realize that the interface was not yet set in stone. > > Parsing -help output and guesswork isn't scalable, and this is not > exactly the first time that people have complained about this. I agree. That's why we try hard to release stable interfaces and then maintain them. > > (Yes, libvirt and libguestfs do allow callers to mechanically query > their respective APIs for capabilities.) Maybe Anthony's (Liguori) rework of the QEMU config interfaces will provide a better reflections, haven't checked. But for now you need to stick with this model, specifically when you want to maintain all the distro forks. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux