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

Re: [Xen-devel] [PATCH] xen : Replace hard coded domain_id checks with a macro



Yes, the idea is to later have it, or another similar macro return true for domids != 0. At the moment, I think it's likely that there will be other separate predicates (maybe something like is_xenstore_domain, is_control_domain, etc) for different disaggregated domains, and then have the last bit continue to use this, even though it may no longer be domid 0.

You're right about the name being ill-chosen, but the only other name I could come up with was is_what_used_to_be_dom0 which was even worse ;) I'm open to suggestions. Perhaps, hardware domain or pci domain?

At the moment, IS_PRIV could be used, but it would lead to a coupling of the privileges with functionality which could be problematic later on.

~M

On Fri, Dec 10, 2010 at 1:08 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Fri, 2010-12-10 at 07:07 +0000, Mihir Nanavati wrote:
> Replace a number of checks for Dom0, that have been hard coded to
> check for domain_id being zero with a macro is_dom0_domain().

Is the intention for this macro return true for some domid != 0 under
some future circumstance? In that case the macro name will turn out to
be badly chosen.

I'm not sure there is any benefit to hard coding a 0 in the function
name as opposed to hardcoding at the call site. I suppose it's a little
easier to search and replace...

Is there a name which describes the actual semantics which the callers
want, as opposed to testing the dom0-ness? Or perhaps there is more than
one desired semantic, in which case multiple predicates would be ok
IMHO. Does the existing IS_PRIV cover some of the cases?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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