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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.04.14 at 11:15, <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.

Urgh - I thought this was about hypervisor code (due to the lack of a
Linux list being Cc-ed) - I fully agree with you for Linux side code.

Jan


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