linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2006-09-30	[PATCH] Use early clobber in semaphores	Andi Kleen	1	-2/+2
	New code clobbers the result always early, so tell gcc about it Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26	[PATCH] Don't use lock section for mutexes and semaphores	Andi Kleen	1	-26/+14
	Lock sections cannot be handled by the dwarf2 unwinder. Disadvantage is a taken branch in the hot path. Signed-off-by: Andi Kleen <ak@suse.de>
2006-06-26	[PATCH] x86_64: x86_64 version of the smp alternative patch.	Gerd Hoffmann	1	-4/+4
	Changes are largely identical to the i386 version: * alternative #define are moved to the new alternative.h file. * one new elf section with pointers to the lock prefixes which can be nop'ed out for non-smp. * two new elf sections simliar to the "classic" alternatives to replace SMP code with simpler UP code. * fixup headers to use alternative.h instead of defining their own LOCK / LOCK_PREFIX macros. The patch reuses the i386 version of the alternatives code to avoid code duplication. The code in alternatives.c was shuffled around a bit to reduce the number of #ifdefs needed. It also got some tweaks needed for x86_64 (vsyscall page handling) and new features (noreplacement option which was x86_64 only up to now). Debug printk's are changed from compile-time to runtime. Loosely based on a early version from Bastian Blank <waldi@debian.org> Signed-off-by: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30	[PATCH] semaphore: Remove __MUTEX_INITIALIZER()	Arthur Othieno	1	-3/+0
	__MUTEX_INITIALIZER() has no users, and equates to the more commonly used DECLARE_MUTEX(), thus making it pretty much redundant. Remove it for good. Signed-off-by: Arthur Othieno <a.othieno@bluewin.ch> 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/+196
	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!