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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
