[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH 1/3] xen: pvhvm: allow user to request no emulated device unplug
On Thu, 2010-08-19 at 17:44 +0100, Jeremy Fitzhardinge wrote: > On 08/19/2010 09:34 AM, Gianni Tedesco wrote: > > On Thu, 2010-08-19 at 17:10 +0100, Jeremy Fitzhardinge wrote: > >> On 08/19/2010 03:54 AM, Stefano Stabellini wrote: > >>> On Thu, 19 Aug 2010, Ian Campbell wrote: > >>>> On Thu, 2010-08-19 at 11:50 +0100, Ian Campbell wrote: > >>>>> On Thu, 2010-08-19 at 11:37 +0100, Stefano Stabellini wrote: > >>>>>> On Thu, 19 Aug 2010, Ian Campbell wrote: > >>>>>>> if (r && !(r == XEN_PLATFORM_ERR_MAGIC && > >>>>>>> + (xen_emul_unplug != -1) && > >>>>>>> (xen_emul_unplug & XEN_UNPLUG_IGNORE))) > >>>>>> I wouldn't add xen_emul_unplug != -1 because it should be clear that > >>>>>> xen_emul_unplug & XEN_UNPLUG_IGNORE always implies xen_emul_unplug != > >>>>>> -1. > >>>>> That's not correct since -1 is all 1s. So you can get a false positive > >>>>> for "xen_emul_unplug & XEN_UNPLUG_IGNORE" if xen_emul_unplug == -1. > >>>> IOW if we were to rewrite the test to use less boolean logic the patch > >>>> might look like: > >>>> > >>>> if (r) { > >>>> if (r != XEN_PLATFORM_ERR_MAGIC) > >>>> return; > >>>> + if (xen_emul_unplug == -1) > >>>> + return; > >>>> if (!(xen_emul_unplug & XEN_UNPLUG_IGNORE)) > >>>> return; > >>>> } > >>>> > >>>> Perhaps this refactoring is worthwhile in any case? It certainly makes > >>>> my head hurt less ;-) > >>>> > >>> > >>> Yeah, it is probably worth it anyway :) > >> Treating a variable as an integer and a bitfield seems like a bad idea. > > Should be fine? I'd just #define XEN_UNPLUG_ALL_THE_BITS ~0U for the > > sake of cosmetics... > > In a bitfield the bits are typically independent, whereas in an integer > you interpret all the bits to get a value. Making "all bits set" mean > something other than all the bitfield bits are set is just asking for > something bad to happen to you. > > Why not define a bit to mean whatever "-1" currently means? I'll add an explicit XEN_UNPLUG_NEVER instead. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |