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

Re: [Xen-devel] [PATCH] xen: fix alignment for bitops



On Tue, 2014-04-15 at 10:30 +0100, Vladimir Murzin wrote:
> On Tue, Apr 15, 2014 at 10:15 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> > On Tue, 2014-04-15 at 09:49 +0100, Jan Beulich wrote:
> >> >>> On 15.04.14 at 10:29, <murzin.v@xxxxxxxxx> wrote:
> >> > On Tue, Apr 15, 2014 at 8:35 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >> >> only place you'd need to alter - we simply assume bitops on 32-bit
> >> >> aligned quantities to work.
> >> >>
> >> >
> >> > You do, but reality seems to be different, apart from arm64 looks like
> >> > ppc64 has the same alignment requirement, I'm not aware about other
> >> > 64-bit implementations... but, is it really possible to convince all
> >> > these people to change the implementation? I guess the answer would be
> >> > "use unsigned long", or like that :)
> >>
> >> That's no the point. The point is that if the arch has such
> >> requirements, the arch-specific bitmap manipulation functions
> >> should be written such that generic code works with the present
> >> assumptions.
> >
> > In this case the interface which arch-specific code has contracted to
> > expose to the generic code is:
> >         extern unsigned long find_first_bit(const unsigned long
> >         *addr, ...
> > i.e. the bitmask is unsigned long (and this is the case for the majority
> > of archs in Linux AFAICS, include asm-generic, note that this differs to
> > Xen which IIRC uses void * here)
> >
> > So it is reasonable IMHO for the Linux arch code to except to be passed
> > something which obeys the alignment rules for an unsigned long.
> >
> > I'm not convinced by the use of __aligned here -- I think it would be
> > better to just use unsigned long.
> 
> It was original idea, but I was in doubt that it didn't break
> interface...

The usage is 
        ready = xchg(&control_block->ready, 0);
and
        ready |= xchg(&control_block->ready, 0);
where control_block->ready is a uint32_t, so  I don't think anything
will be broken (at least so long as sizeof(unsigned long) >=
sizeof(uint32_t), which I think we can rely on)

> Should I send v2 or wait for other proposals?

I'd wait for the Linux maintainers to speak up.

Ian.


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


 


Rackspace

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