An error occurred fetching the project authors.
- 04 Oct, 2008 1 commit
-
-
Paul Bolle authored
Since v.2.6.23 DEF_INITSEG and DEF_SETUPSEG are unused. Commit c3973682 ("Remove old i386 setup code") dropped their usage for i386. They did not return in the x86 tree. (Something similar must have happened for x86_64.) Remove these. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
- 22 Jul, 2008 1 commit
-
-
Vegard Nossum authored
This patch is the result of an automatic script that consolidates the format of all the headers in include/asm-x86/. The format: 1. No leading underscore. Names with leading underscores are reserved. 2. Pathname components are separated by two underscores. So we can distinguish between mm_types.h and mm/types.h. 3. Everything except letters and numbers are turned into single underscores. Signed-off-by:
Vegard Nossum <vegard.nossum@gmail.com>
-
- 19 Apr, 2008 1 commit
-
-
Alexander van Heukelum authored
The kernel decompressor wrapper uses memory located beyond the end of the image. This might lead to hard to debug problems, but even if it can be proven to be safe, it is at the very least unclean. I don't see any advantages either, unless you count it not being zeroed out as an advantage. This patch moves the boot-heap area to the bss segment. Signed-off-by:
Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 11 Oct, 2007 1 commit
-
-
Thomas Gleixner authored
Move the headers to include/asm-x86 and fixup the header install make rules Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
- 12 Jul, 2007 1 commit
-
-
H. Peter Anvin authored
include/asm-i386/boot.h incorrectly has the multiple include guards as _LINUX_BOOT_H instead of _ASM_BOOT_H. Fix. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 09 May, 2007 1 commit
-
-
Robert P. J. Day authored
Fix the misspellings of "propogate", "writting" and (oh, the shame :-) "kenrel" in the source tree. Signed-off-by:
Robert P. J. Day <rpjday@mindspring.com> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
- 06 Jan, 2007 1 commit
-
-
Vivek Goyal authored
o Relocatable bzImage support had got rid of CONFIG_PHYSICAL_START option thinking that now this option is not required as people can build a second kernel as relocatable and load it anywhere. So need of compiling the kernel for a custom address was gone. But Magnus uses vmlinux images for second kernel in Xen environment and he wants to continue to use it. o Restoring the CONFIG_PHYSICAL_START option for the time being. I think down the line we can get rid of it. Signed-off-by:
Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 07 Dec, 2006 1 commit
-
-
Vivek Goyal authored
o Now CONFIG_PHYSICAL_START is being replaced with CONFIG_PHYSICAL_ALIGN. Hardcoding the kernel physical start value creates a problem in relocatable kernel context due to boot loader limitations. For ex, if somebody compiles a relocatable kernel to be run from address 4MB, but this kernel will run from location 1MB as grub loads the kernel at physical address 1MB. Kernel thinks that I am a relocatable kernel and I should run from the address I have been loaded at. So somebody wanting to run kernel from 4MB alignment location (for improved performance regions) can't do that. o Hence, Eric proposed that probably CONFIG_PHYSICAL_ALIGN will make more sense in relocatable kernel context. At run time kernel will move itself to a physical addr location which meets user specified alignment restrictions. Signed-off-by:
Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
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!
-