Yes, on the generic it is int. The problem is in part that some architectures have bitop instructions with specific behavior.
Joe Perches <j...@perches.com> wrote: >On Tue, 2013-07-16 at 18:15 -0700, tip-bot for H. Peter Anvin wrote: >> Commit-ID: 9b710506a03b01a9fdd83962912bc9d8237b82e8 >[] >> x86, bitops: Change bitops to be native operand size >> >> Change the bitops operation to be naturally "long", i.e. 63 bits on >> the 64-bit kernel. Additional bugs are likely to crop up in the >> future. > >> We already have bugs which machines with > 16 TiB of memory in a >> single node, as can happen if memory is interleaved. The x86 bitop >> operations take a signed index, so using an unsigned type is not an >> option. > >I think it odd that any bitop index nr should be >anything other than unsigned long for any arch. > >Why should this arch be any different than the >defined type in Documentation/atomic_ops.txt? > >What value is a negative index when the bitmap >array address passed is the starting 0th bit? > >btw: asm-generic/bitops.h doesn't match >Documentation/atomic_ops.txt either. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
