[Libvirt-cim] [PATCH] [RFC] Changes required to work with new std_indication. The trigger changes were very light, which was nice

Dan Smith danms at us.ibm.com
Fri Feb 8 15:06:58 UTC 2008


I agree with Heidi.  I think you've opened the door to take it a
little further so that the calls in Enable/Disable and
Activate/Deactivate are automated for the simple case.  Maybe this is
already planned?

JG> +static struct std_ind_state migrate = {
JG> +        .ind_name = "Xen_ComputerSystemMigrationIndication",
JG> +        .filter_active = false,
JG> +        .enabled = false,
JG> +};

This is a really minor thing, but this definition has some fields that
must always be set to false on initialization to avoid badness.  Now,
since these are static, they are all initialized to zero, which should
cover you in the case that someone just doesn't set filter_active and
enabled.  However, perhaps setting the precedent with something like a
constructor macro would be appropriate?

  #define DECLARE_IND(ident, name)              \ 
          static struct std_ind_state ident = { \
                 .ind_name = name,              \
                 .filter_active = false,        \
                 .enabled = false,              \
          };

Which would make the above definition look like this:

  DECLARE_IND(migrate, "Xen_ComputerSystemMigrationIndication");

Thoughts?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080208/78dd8071/attachment.sig>


More information about the Libvirt-cim mailing list