From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGDqO-00008M-JN for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:11:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGDqK-00007z-4A for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:11:32 -0400 Received: from [199.232.76.173] (port=59883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGDqJ-00007w-SH for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:11:27 -0400 Received: from qw-out-1920.google.com ([74.125.92.148]:17571) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGDqJ-0006WE-Hw for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:11:27 -0400 Received: by qw-out-1920.google.com with SMTP id 4so1824158qwk.4 for ; Mon, 15 Jun 2009 08:11:26 -0700 (PDT) Message-ID: <4A366484.7070602@codemonkey.ws> Date: Mon, 15 Jun 2009 10:11:00 -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: <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> <4A365890.1050106@codemonkey.ws> <20090615143406.GA14405@redhat.com> In-Reply-To: <20090615143406.GA14405@redhat.com> 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: "Michael S. Tsirkin" Cc: Mark McLoughlin , kvm@vger.kernel.org, Carsten Otte , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Avi Kivity , Paul Brook Michael S. Tsirkin wrote: > And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be > more straightforward to have capability bits which can be switched on > and off independently rather than trying to fit unrelated features into > a machine type? IMO it only seems more work at first, and QA gets a bit > nervious that they can't exhaustively test all options. But in the long > run it simplifies things as you don't have to set policy and invent > silly names. > We're strictly talking about default machine configs. That has nothing to do with capabilities. You still need to know what the default set of enabled capabilities were and keep track of that. All that I'm suggesting is that we use the machine name to collapse the default set of capabilities into something that libvirt can track. The advantage of using something more opaque like that is that it simplifies things for management tools as they don't have to keep track of "capabilities" that we're adding. Heck, you could even do: pc-00000034 Where "pc-%08x" % (capabilities) :-) Regards, Anthony Liguori