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

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



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

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

 


Rackspace

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