From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] Date: Mon, 15 Jun 2009 09:20:00 -0500 Message-ID: <4A365890.1050106@codemonkey.ws> 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> <4A326C7E.3020309@codemonkey.ws> <1244822007.30522.68.camel@blaa> <4A327E87.6080005@codemonkey.ws> <1244825333.26769.20.camel@blaa> <4A34ADA9.80709@redhat.com> <1245056955.6891.33.camel@blaa> <4A36314A.8040206@redhat.com> <4A364316.5070402@codemonkey.ws> <1245074447.3222.53.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Jamie Lokier , "Michael S. Tsirkin" , Carsten Otte , kvm@vger.kernel.org, Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook To: Mark McLoughlin Return-path: Received: from mail-gx0-f214.google.com ([209.85.217.214]:44571 "EHLO mail-gx0-f214.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752257AbZFOOUA (ORCPT ); Mon, 15 Jun 2009 10:20:00 -0400 Received: by gxk10 with SMTP id 10so6530405gxk.13 for ; Mon, 15 Jun 2009 07:20:03 -0700 (PDT) In-Reply-To: <1245074447.3222.53.camel@blaa> Sender: kvm-owner@vger.kernel.org List-ID: Mark McLoughlin wrote: > On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote: > >>> Eventually the >>> default configuration becomes increasingly unusable and you need a new >>> baseline. You must still be able to fall back to the old baseline for >>> older guests. I don't think games with configuration files can hide >>> that. >>> >> -M pc1 >> -M pc2 >> >> etc. >> >> This is pretty easy to maintain with config files. >> > > I think this would be reasonable, but it is essentially just a version > number which you objected to on the basis that it would make > cherry-picking harder for distros. > It doesn't have to be pc1, pc2. It could be pc-with-usb or pc-with-balloon. If a distro cherry picks in such a way that their pc is not a standard QEMU pc, they would add a new PC type that's specific to their distro. > One thing that would be nice with this '-M pc1' thing would be to retain > '-M pc' as a symlink to the latest version. We'd also need a way to read > the symlink too, so that you can query what the current latest version > is and use that in future. > Another option is an explicit -M default which always uses the default machine for the architecture. Likewise, we would need a way to query what the default machine was for an architecture. > How would this machine type version relate to e.g. changing the default > PCI class of virtio-blk? Would we bump the version number of all machine > types can use virtio-blk? > You would introduce a new machine type. For instance, pc-virtio-class-other. The names don't have to look like that, I'm just doing that to make a point. This may mean that you end up with dozens of machine types but you preserve compatibility, which is a good thing. Of course, the flip side is that you make preserving the machine config the duty of the user and we don't maintain compatible machine types. This won't work without a proper config file though so for now, we're stuck maintaining machine types. Regards, Anthony Liguori