Re: [libvirt] [PATCHv2 18/27] xen: reject unknown flags

On 07/13/2011 06:59 AM, Matthias Bolte wrote: > 2011/7/8 Eric Blake <eblake(a)redhat.com&gt;: >> @@ -1629,8 +1633,10 @@ xenDaemonDomainSave(virDomainPtr domain, const char *filename) >>  */ >>  static int >>  xenDaemonDomainCoreDump(virDomainPtr domain, const char *filename, >> -                        unsigned int flags ATTRIBUTE_UNUSED) >> +                        unsigned int flags) >>  { >> +    virCheckFlags(0, -1); >> + >>     if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) || >>         (filename == NULL)) { >>         virXendError(VIR_ERR_INVALID_ARG, __FUNCTION__); > > Third time fooled by ATTRIBUTE_UNUSED. xenDaemonDomainCoreDump > understands VIR_DUMP_LIVE and VIR_DUMP_CRASH. Yep, which is why for v3, I've gone through and looked at every use of virCheckFlags(0, ...) to make sure that the next instance of 'flags' is not until the next function.  I'll respin this patch for my v3 series. In the meantime, I've pushed 16 and 17. > >> @@ -3151,10 +3160,12 @@ xenDaemonDomainMigratePrepare (virConnectPtr dconn, >>                                int *cookielen ATTRIBUTE_UNUSED, >>                                const char *uri_in, >>                                char **uri_out, >> -                               unsigned long flags ATTRIBUTE_UNUSED, >> +                               unsigned long flags, >>                                const char *dname ATTRIBUTE_UNUSED, >>                                unsigned long resource ATTRIBUTE_UNUSED) >>  { >> +    virCheckFlags(0, -1); >> + >>     /* If uri_in is NULL, get the current hostname as a best guess >>      * of how the source host should connect to us.  Note that caller >>      * deallocates this string. > > This breaks virDomainMigrate, because *DomainMigratePrepare is called > with the flags passed to virDomainMigrate, even if > xenDaemonDomainMigratePrepare doesn't use this flags it has to accept > all flags that the Xen driver understand in general form migration. Good point, and somewhat relevant to your comments about ESX migration flags in 8/27 as well. I will also double-check that qemu and remote (the only other drivers with a MigratePrepare callback) are not affected.