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@xxxxxxxxxx +1-801-349-2682 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