qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Avi Kivity
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 20:09:22 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]