From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGFiU-0000Fe-FD for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:11:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGFiP-0000EK-0N for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:11:29 -0400 Received: from [199.232.76.173] (port=47707 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGFiO-0000EH-T1 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:11:24 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36542) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGFiO-0002y1-Cr for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:11:24 -0400 Message-ID: <4A368042.7060502@redhat.com> Date: Mon, 15 Jun 2009 20:09:22 +0300 From: Avi Kivity 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: <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com> <1245056916.6891.31.camel@blaa> <4A3613EC.6030608@redhat.com> <20090615103249.GB6351@redhat.com> <4A363012.8050409@redhat.com> <20090615114858.GG6351@redhat.com> <4A3636FA.1040609@redhat.com> <20090615124101.GH6351@redhat.com> <4A364381.401@redhat.com> <4A364401.6010500@codemonkey.ws> <4A3647FB.9010808@redhat.com> <4A364B53.9080007@codemonkey.ws> <4A364FE0.40204@redhat.com> <4A3651EB.3070204@codemonkey.ws> <4A36555A.4090303@redhat.com> <4A3659A0.3050108@codemonkey.ws> <4A366348.1030202@redhat.com> <1245083229.3222.103.camel@blaa> In-Reply-To: <1245083229.3222.103.camel@blaa> Content-Type: multipart/alternative; boundary="------------000404090704080701010503" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Carsten Otte , dlaor@redhat.com, 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 This is a multi-part message in MIME format. --------------000404090704080701010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/15/2009 07:27 PM, Mark McLoughlin wrote: >> However this may end up, isn't it offtopic? Whatever we do we have to >> support both pci_addr= and default placement, so we can push this >> discussion to livirt-devel and bid them godspeed. >> > > Presumably you're not proposing that qemu-devel completely ignore the > typical requirements of management apps? > We propose to allow both qemu-allocated slots and user-allocated slots, so we're only ignoring the actual decision by the management tool providers, not their requirements. > You can push the discussion to libvirt-devel, and the conclusion would > most likely be: > > "We can do slot allocation if you provide us with a way to query free > slots, or we can use qemu's default allocation if you provide us a > way to query the allocation. > > We'd prefer the default allocation problem, but we don't really > care. Both require about the same amount of work for us." > Well, they'll find out if they try default allocation. It's traditional to try all the complicated solutions before trying the simplest one, so I guess we'll just have to let them. > libvirt was only mentioned in this thread as a concrete example of how > the suggested solutions would actually be used by management apps. > True, others will wind up doing things differently. In fact, I'm a little surprised that libvirt is involved, since the place to do inventory is in the management app itself (it's true that libvirt also maintains its own database, so the line is blurred). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --------------000404090704080701010503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/15/2009 07:27 PM, Mark McLoughlin wrote:
However this may end up, isn't it offtopic?  Whatever we do we have to 
support both pci_addr= and default placement, so we can push this 
discussion to livirt-devel and bid them godspeed.
    

Presumably you're not proposing that qemu-devel completely ignore the
typical requirements of management apps?

We propose to allow both qemu-allocated slots and user-allocated slots, so we're only ignoring the actual decision by the management tool providers, not their requirements.

You can push the discussion to libvirt-devel, and the conclusion would
most likely be:

  "We can do slot allocation if you provide us with a way to query free 
   slots, or we can use qemu's default allocation if you provide us a
   way to query the allocation.

   We'd prefer the default allocation problem, but we don't really 
   care. Both require about the same amount of work for us."

Well, they'll find out if they try default allocation.  It's traditional to try all the complicated solutions before trying the simplest one, so I guess we'll just have to let them.

libvirt was only mentioned in this thread as a concrete example of how
the suggested solutions would actually be used by management apps.

True, others will wind up doing things differently.  In fact, I'm a little surprised that libvirt is involved, since the place to do inventory is in the management app itself (it's true that libvirt also maintains its own database, so the line is blurred).
-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--------------000404090704080701010503--