On 05/24/2010 02:20 PM, Chris Lalancette wrote:
> Sounds good to me - if all entry points filter on all accepted
flags,
> then helper functions can assume that flags are already valid. As long
> as the filtering gets done somewhere, we've left the door open for
> adding future flags while still correctly identifying situations where
> we are talking to older implementations that can't honor new flags.
> It's only when there is no flag filtering at all that we've locked
> ourselves out of easy-to-validate future extensions.
Unfortunately doing this caused a bit of churn in the qemu driver. qemudDomainMigrate
takes an unsigned long as flags instead of unsigned int, which required me to create
two new macros: virCheckFlagsUI and virCheckFlagsUL. The good news is that with this
patch in place we are doing more checking of the flags during migration, which is
probably a good thing. A new patch is coming up.
Hmm, since virCheckFlags() is already a macro in the first place, can we
use some sizeof(flags) magic to get it to polymorphically do the right
thing rather than having to invent an alternate spelling?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org