Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
>> Jeff, are you okay with u32 or 64?
> 
> unsigned long is IMO the best choice for bitmaps.
> 
> * it is a machine int on all(?) architectures

I don't really see much point in this.  What's the advantage of a
machine int for xfer mask?

> * it is 32-bit on 32-bit architectures

The problem I see for using native integral types for flags or mask is
that it's not fixed in size, so you can only use the smallest of all the
supported architectures.  We know for all archs we support, both
unsigned int and unsigned long are at least 32bits long but to me making
the assumption about expected number of bits using u32 or u64 is much
more important than other considerations.

> * it is consistent with test_bit(), set_bit() and lib/bitmap.c interfaces
> 
> * conversion to test_bit() and lib/bitmap.c interfaces as a future step
> is trivial

I don't think it's likely that we'll need those heavy machineries for
xfermask and the correct approach is to convert when the need actually
arises.

> * your structs inflate on 64-bit due to pointers anyway, so I see little
> real consequence to using the lower 32 bits of an unsigned long as a
> portable meme.

I'm not trying to optimize performance or size.  I'm trying to make
programming assumptions clear.  I think it's silly to optimize anything
for xfermask.  It just has to work and be clear to people working with it.

An optimal but overkill solution would be using fast_u32 or fast_u64
types such that the compiler can choose as necessary but as we don't
have that yet && xfermask handling is a very very cold path, I think we
should be aiming for clarity.

Thanks.

-- 
tejun