From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF86A-0000Sx-9v for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:51:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF865-0000QJ-EG for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:51:17 -0400 Received: from [199.232.76.173] (port=52699 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF865-0000QG-5v for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:51:13 -0400 Received: from mail-gx0-f207.google.com ([209.85.217.207]:45799) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF865-0004Qx-6D for qemu-devel@nongnu.org; Fri, 12 Jun 2009 10:51:13 -0400 Received: by gxk3 with SMTP id 3so9460683gxk.10 for ; Fri, 12 Jun 2009 07:51:12 -0700 (PDT) Message-ID: <4A326B5C.5010501@codemonkey.ws> Date: Fri, 12 Jun 2009 09:51:08 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] References: <20090610145540.GI19375@poweredge.glommer> <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> <20090610174301.GC7416@shareable.org> <20090610182227.GN28601@redhat.com> <20090610192702.GH7416@shareable.org> <1244796209.16425.20.camel@blaa> In-Reply-To: <1244796209.16425.20.camel@blaa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Carsten Otte , kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook , Avi Kivity Mark McLoughlin wrote: > On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote: > >> Michael S. Tsirkin wrote: >> >>>> I think the right long term answer to all this is a way to get QEMU to >>>> dump it's current machine configuration in glorious detail as a file >>>> which can be reloaded as a machine configuration. >>>> >>> And then we'll have the same set of problems there. >>> >> We will, and the solution will be the same: options to create devices >> as they were in older versions of QEMU. It only needs to cover device >> features which matter to guests, not every bug fix. >> >> However with a machine configuration which is generated by QEMU, >> there's less worry about proliferation of obscure options, compared >> with the command line. You don't necessarily have to document every >> backward-compatibility option in any detail, you just have to make >> sure it's written and read properly, which is much the same thing as >> the snapshot code does. >> > > This is a sensible plan, but I don't think we should mix these compat > options in with the VM manager supplied configuration. > > There are two problems with that approach. > > = Problem 1 - VM manager needs to parse qemu config = > > Your proposal implies: > > - VM manager supplies a basic configuration to qemu > > - It then immediately asks qemu for a dump of the machine > configuration in all its glorious detail and retains that > config > > - If the VM manager wishes to add a new device it needs to parse the > qemu config and add it, rather than just generate an entirely new > config > What's the problem with parsing the device config and modifying it? Is it just complexity? If we provided a mechanism to simplify manipulating a device config, would that eliminate the concern here? Regards, Anthony Liguori