Re: [Xen-devel] [PATCH 11/16] x86/monitor: fix: treat -monitor- properly, as a subsys of the vm-event subsys

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Mon, Jul 11, 2016 at 2:20 PM, Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx> wrote:
> On 7/11/2016 7:38 PM, Tamas K Lengyel wrote:
>>>>>
>>>>> diff --git a/xen/include/asm-arm/monitor.h
>>>>> b/xen/include/asm-arm/monitor.h
>>>>> index 9a9734a..7ef30f1 100644
>>>>
>>>> [snip]
>>>
>>>
>>> I keep seeing '[snip]' lately but I don't know what it means.
>>
>> Placeholder for "I've cut some of your patch content here to shorten
>> the message I'm sending".
>>
>>>>> diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
>>>>> index 2171d04..605caf0 100644
>>>>> --- a/xen/include/xen/monitor.h
>>>>> +++ b/xen/include/xen/monitor.h
>>>>> @@ -22,12 +22,15 @@
>>>>>    #ifndef __XEN_MONITOR_H__
>>>>>    #define __XEN_MONITOR_H__
>>>>>
>>>>> -#include <public/vm_event.h>
>>>>> -
>>>>> -struct domain;
>>>>> -struct xen_domctl_monitor_op;
>>>>> +#include <xen/sched.h>
>>>>>
>>>>>    int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op
>>>>> *op);
>>>>> +
>>>>> +static inline bool_t monitor_domain_initialised(const struct domain
>>>>> *d)
>>>>> +{
>>>>> +    return d->monitor.initialised;
>>>>
>>>> This should be !!d->monitor.initialised.
>>>
>>>
>>> It's the value of a bit, thus should be 0 or 1. Am I missing something?
>>
>> Using a bitfield is effectively doing a bitmask for the bit(s).
>> However, returning the value after applying a bitmask is not
>> necessarily 0/1 (ie. bool_t). For example I ran into problems with
>> this in the past (see
>> https://lists.xen.org/archives/html/xen-devel/2015-08/msg01948.html).
>>
>> Tamas
>
>
> The example you provided actually returns a value &-ed with a flag
> (bitmask), of course it returns either 0 or the flag itself :-). AFAIK a
> single-bit item in a bitfield (note a -bitfield-, not e.g. an unsigned int
> &-ed with (1<<x)) will always be either 0 or 1.
>

I would assume as well but I'm not actually sure if that's guaranteed
or if it's only compiler defined behavior.

Tamas

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