WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Mihir Nanavati <mihirn@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen : Replace hard coded domain_id checks with a macro
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 10 Dec 2010 10:44:16 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Dec 2010 02:47:10 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=oVFpJiL9nT2BzTm4auu1my2Lbii+XwinSBgwX@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <AANLkTikP5kGGuTSPzAZbDXktxdYNxB=hyGVVraHf1vAB@xxxxxxxxxxxxxx> <1291972103.13966.4701.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=oVFpJiL9nT2BzTm4auu1my2Lbii+XwinSBgwX@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-12-10 at 10:13 +0000, Mihir Nanavati wrote:
> 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?

I don't have any better suggestions :-(

I think it very much depends on what the call site is actually trying to
test and how it will be disaggregated in the future. If you are just
going to have to switch to another macro when you do the disaggregation
what's the benefit of switching now?

> 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