[libvirt] [PATCH 08/12] vcpu: support maxvcpu in domain_conf

[Daniel Veillard]

On Mon, Oct 04, 2010 at 12:18:00PM -0600, Eric Blake wrote:
> On 10/01/2010 09:01 AM, Daniel Veillard wrote:
> >On Wed, Sep 29, 2010 at 06:02:12PM -0600, Eric Blake wrote:
> >>* src/conf/domain_conf.h (_virDomainDef): Adjust vcpus to unsigned
> >>short, to match virDomainGetInfo limit.  Add maxvcpus member.
> >[...]
> >>
> >>Two tightly-related changes.  One: virDomainGetInfo implicitly limits
> >>vcpus to a 16-bit number; so there's no need to pretend otherwise
> >>through the rest of the code.
> >
> >  well, yes and no, in a few years we may look ridiculous, but it would
> >  be good to have the new APIs cleared up from that limitation.
> 
> So, should I keep the change to 16-bit in my v2 series, or should I
> keep things at 32-bit and add code that makes virDomainGetInfo fail
> on 16-bit overflow?  Right now, it's easier to keep things at 16-bit
> throughout. Also, note that the new APIs (virDomainGetVcpusFlags and
> virDomainSetVcpusFlags) can go up to 31 bits.  Get must return -1 on
> failure, so a full 32-bits cannot be returned; so even though Set
> passes an unsigned value, we should not accept 0x80000000, even if
> we decide someday that we want to support 0x10000 vcpus.

  No need for it now. What you're adding is to an internal data
structure, that's not part of any API, so it's just fine (i.e.
we will just be able to bump up the type if the need arise).

The problem is the structure from the API using a short.
All the other new APIs return ints so I think we should be safe there.

  so no need to change the patches IMHO

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/