[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |