wireguard-linux/include/asm-parisc/types.h, branch stable

parisc: move include/asm-parisc to arch/parisc/include/asm

2008-10-10T16:32:29Z

parisc: types: use for the parisc architecture

2008-05-02T23:18:32Z

This modifies to use the generic include files. Signed-off-by: H. Peter Anvin Cc: Kyle McMartin Cc: Matthew Wilcox Cc: Grant Grundler

remove strict ansi check from __u64 in asm/types.h

2007-10-17T15:42:53Z

Remove the __STRICT_ANSI__ check from the __u64/__s64 declaration on 32bit targets. GCC can be made to warn about usage of long long types with ISO C90 (-ansi), but only with -pedantic. You can write this in a way that even then it doesn't cause warnings, namely by: #ifdef __GNUC__ __extension__ typedef __signed__ long long __s64; __extension__ typedef unsigned long long __u64; #endif The __extension__ keyword in front of this switches off any pedantic warnings for this expression. Signed-off-by: Olaf Hering Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PARISC] convert to use CONFIG_64BIT instead of LP64

2007-02-17T06:17:13Z

Signed-off-by: Helge Deller Signed-off-by: Kyle McMartin

[PARISC] Update bitops from parisc tree

2005-10-22T02:45:22Z

Optimize ext2_find_next_zero_bit. Gives about 25% perf improvement with a rsync test with ext3. Signed-off-by: Randolph Chung fix ext3 performance - ext2_find_next_zero() was culprit. Kudos to jejb for pointing out the the possibility that ext2_test_bit and ext2_find_next_zero() may in fact not be enumerating bits in the bitmap because of endianess. Took sparc64 implementation and adapted it to our tree. I suspect the real problem is ffz() wants an unsigned long and was getting garbage in the top half of the unsigned int. Not confirmed but that's what I suspect. Signed-off-by: Grant Grundler Fix find_next_bit for 32-bit Make masking consistent for bitops From: Joel Soete Signed-off-by: Randolph Chung Add back incorrectly removed ext2_find_first_zero_bit definition Signed-off-by: James Bottomley Fixup bitops.h to use volatile for *_bit() ops Based on this email thread: http://marc.theaimsgroup.com/?t=108826637900003 In a nutshell: *_bit() want use of volatile. __*_bit() are "relaxed" and don't use spinlock or volatile. other minor changes: o replaces hweight64() macro with alias to generic_hweight64() (Joel Soete) o cleanup ext2* macros so (a) it's obvious what the XOR magic is about and (b) one version that works for both 32/64-bit. o replace 2 uses of CONFIG_64BIT with __LP64__. bitops.h used both. I think header files that might go to user space should use something userspace will know about (__LP64__). Signed-off-by: Grant Grundler Move SHIFT_PER_LONG to standard location for BITS_PER_LONG (asm/types.h) and ditch the second definition of BITS_PER_LONG in bitops.h Signed-off-by: Grant Grundler Signed-off-by: Kyle McMartin

[PATCH] sab: consolidate kmem_bufctl_t

2005-09-05T07:05:48Z

This is used only in slab.c and each architecture gets to define whcih underlying type is to be used. Seems a bit silly - move it to slab.c and use the same type for all architectures: unsigned int. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!