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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/