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

[Keir Fraser <keir@xxxxxxx>]

Yeah, that's the pain of an out-of-tree patch queue I'm afraid. You have to
suck it up. :-)

On 10/12/2010 11:06, "Mihir Nanavati" <mihirn@xxxxxxxxx> wrote:

> Fair enough, I guess it's more useful for us here in testing to be able to
> switch to having another domid as dom0 from a single place then it would be in
> a production system. Will keep it on hold till we've gotten some more pieces
> into place.
> 
> ~M
> 
> On Fri, Dec 10, 2010 at 2:42 AM, Keir Fraser <keir@xxxxxxx> wrote:
>> I'm undecided. The patch by itself is kind of harmless but also kind of
>> pointless. Probably we should leave this until you have something more
>> substantial to propose. Trickling in trivial patches like this is a waste of
>> time.
>> 
>>  -- Keir
>> 
>> On 10/12/2010 10:13, "Mihir Nanavati" <mihirn@xxxxxxxxx> 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?
>>> 
>>> 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
>> 
>> 
> 
> 



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