[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 5/5] xen/xsm: include default hook action in name



Hi, 

At 09:51 -0500 on 20 Nov (1353405098), Daniel De Graaf wrote:
> Include the default XSM hook action in the name of the hook in order to
> allow quick understanding of how the call site is expected to be used
> (dom0-only, arbitrary guest, or target-only).

I like this a lot; it's much less worrying than having to follow every
xsm hook to see what it does. 

I would like it even more if the process were automatic -- as it stands
your dummy hooks must be manually coded to do what their name implies,
and if the code gets out of sync with the name it could be a long time
before anyone spotted it.

Would it be acceptable for every XSM hook to take a default action as
its first argument?  Then the call sites look like:

  xsm_do_mca(XSM_PRIV),
  xsm_unbind_pt_irq(XSM_HOOK, d, bind);

and so forth, and every one of the dummy hooks is just a wrapper around
a single central hook that DTRT with the default:

  static XSM_INLINE int xsm_do_mca(xsm_default_t default)
  {
        return xsm_default_action(default);
  }

  static XSM_INLINE int xsm_unbind_pt_irq(xsm_default_t default, struct domain 
*d, struct xen_domctl_bind_pt_irq *bind)
  {
        return xsm_default_action(default);
  }

and so forth.  It should be very hard to get it wrong.  I guess there
might have to be a standard order for things that take a domain or an
mfn, but do you think something along those lines could work?

If adding an arg is too much overhead I'm sure the dummy ops could 
be autogenerated from the name with some nasty CPP. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.