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.
>>
>
>
>
