From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9fUh-0007ne-S4 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:31:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9fUf-00024r-R0 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:31:39 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:40210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9fUf-00024j-Kk for qemu-devel@nongnu.org; Mon, 19 Mar 2012 12:31:37 -0400 Received: by dadp14 with SMTP id p14so11246920dad.4 for ; Mon, 19 Mar 2012 09:31:34 -0700 (PDT) Message-ID: <4F675F63.7070305@codemonkey.ws> Date: Mon, 19 Mar 2012 11:31:31 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1332169763-30665-1-git-send-email-aliguori@us.ibm.com> <4F675A55.5080000@redhat.com> In-Reply-To: <4F675A55.5080000@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Eric Blake , Gerd Hoffman , Eduardo Habkost , qemu-devel@nongnu.org On 03/19/2012 11:09 AM, Paolo Bonzini wrote: > Il 19/03/2012 16:09, Anthony Liguori ha scritto: >> Hi, >> >> I didn't start out intending to write this series, but I end up here trying to >> resolve an issue in the gtk UI. > > What issue? :) I rewrote the scaling support and did some usability testing with my unsuspecting wife... To make a long story short, my take away was that I need a way to have persistent configuration options. That got me looking at readconfig/writeconfig. > >> This series does some dramatic refactoring to -readconfig essentially throwing >> away the existing (trivial) implementation and replacing it with glib's >> GKeyFile support. > > Nice. > >> It also plumbs the existing command line options through QemuOpts via a special >> 'system' section. This means that any command line option can be specified via >> readconfig and that the combination of -nodefconfig and -writeconfig should give >> you exactly the same guest in a repeatable fashion. > > I don't like this because it turns command-line options into ABI. It's already an ABI, no? > Also, > it puts there some options for which -writeconfig is actually able to > produce a QemuOpts equivalent, such as -monitor. That may be a bug depending on what your concern is. Can you be more specific? > I have a few patches here that convert almost every option that matters > into QemuOpts so that -writeconfig records it: -m, -bios, -localtime, > -S, -M, -smp, -numa, -nodefaults, -no-shutdown, -no-reboot. The only > thing that is left basically is -display, where I chickened out. This series is complimentary to this. You can still promote options to QemuOpts. The advantage of this series is that we provide a programmatic way for libvirt to discover when this happens. If you look at the management guide that I included, I made a strong statement that we promise to never extend existing options without first converting to QemuOpts. > >> Finally, this series exposes a new -query-capabilities option which dumps the >> QemuOpts schema's via JSON to standard output (along with some other goodies >> like the version info and supported QMP commands). >> >> The purpose of this series is to change the way management tools (esp libvirt) >> interact with QEMU to determine capabilities. Instead of help parsing, libvirt >> should use -query-capabilities to figure out which options are supported and >> when new suboptions are available. >> >> I would like to push this series into 1.1 > > I think it's too early. However, we can definitely apply 1/2/7/8/9 now. Let's go through the discussion and see where we end up. I was just stating my intentions so that folks reviewed appropriately. But I realize there's a lot of discussion that needs to happen before we make this type of commitment for 1.1. Regards, Anthony Liguori > > Paolo >