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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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