linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2005-07-28	[PATCH] x86_64: Fix gcc 4 warning in sched_find_first_bit	Jesse Millan	1	-2/+1
	This patch eliminates the GCC4 warning on the x86_64 platform: kernel/sched.c:1824: warning: control may reach end of non-void function 'sched_find_first_bit' being inlined. The change follows the lead of others, i.e. it is guaranteed that at least one of b[0], b[1], or b[2] will have a bit set and evaluate to true. That being said, GCC4.0.0 notices that the code flow does not return anything if b[0], b[1] and b[2] are not true. Since we know better, if it's not b[0] or b[1], it has to be b[2]. Signed-off-by: Jesse Millan <jessem@cs.pdx.edu> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23	[PATCH] add x86-64 specific support for sparsemem	Matt Tolentino	1	-2/+0
	This patch adds in the necessary support for sparsemem such that x86-64 kernels may use sparsemem as an alternative to discontigmem for NUMA kernels. Note that this does no preclude one from continuing to build NUMA kernels using discontigmem, but merely allows the option to build NUMA kernels with sparsemem. Interestingly, the use of sparsemem in lieu of discontigmem in NUMA kernels results in reduced text size for otherwise equivalent kernels as shown in the example builds below: text data bss dec hex filename 2371036 765884 1237108 4374028 42be0c vmlinux.discontig 2366549 776484 1302772 4445805 43d66d vmlinux.sparse Signed-off-by: Matt Tolentino <matthew.e.tolentino@intel.com> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+418
	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!