On 02/13/2014 06:50 AM, Claudio Bley wrote: > > The docs say: > >> If the guest is inactive, this is basically the same as >> virConnectGetMaxVcpus(). If the guest is running this will reflect >> the maximum number of virtual CPUs the guest was booted with. > > But, apparently, all the driver implementations for > virDomainGetMaxVcpus forward to > <driver>DomainGetVcpusFlags(.., VIR_DOMAIN_AFFECT_LIVE | VIR_DOMAIN_VCPU_MAXIMUM). > _______________________________,~~~~~~~~~~~~~~~~~~~~~~ > Looks like I caused a regression when I added the Flags variant in 2010 (that was my first real API addition when I was new to libvirt coding, if I recall). Fixing the code to match the docs sounds like the right way to go here. > > To be honest, I'm not sure whether this worked as described at some > time in the past _at all_. > > How to fix this? Change the documentation or the flag? The newer Flags API should be preferred, but that doesn't mean we can't fix the older API to behave more sanely. On the back-compat perspective, changing something that used to fail into something that now succeeds is okay (you can tell whether you are talking to an older libvirt by whether the failure happens). [The opposite direction of changing something that succeeds into an error is not nice unless it is done to plug a security hole, since older code may be depending on the success path and should not need to be rewritten to new API just to keep things working] -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list