On 05/24/2010 04:34 PM, Eric Blake wrote:
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?
We discussed this on IRC. Unfortunately I don't think you can use sizeof()
directly, since on 32-bit sizeof(unsigned int) == sizeof(unsigned long). However,
what I've done instead is to unconditionally promote flags to an unsigned long
and then use %lx. That seems to work. I'll post v3 of the patch in a moment.
--
Chris Lalancette