31 Jan, 2009
1 commit
-
fix the following 'make headers_check' warning:
usr/include/linux/edd.h:70: found __[us]{8,16,32,64} type without #include
Signed-off-by: Jaswinder Singh Rajput
23 Oct, 2007
1 commit
-
To actually write a bootloader (or, say, the lguest launcher)
currently requires duplication of these structures. Making them
includable from userspace is much nicer.We merge the common userspace-required definitions of e820_32/64.h
into e820.h for export.Signed-off-by: Rusty Russell
13 Jul, 2007
1 commit
-
This removes the old i386 setup code. This is done as a separate patch
to avoid breaking git bisect as some of the i386 code was also used by
the old x86-64 code.Signed-off-by: H. Peter Anvin
Signed-off-by: Linus Torvalds
26 Sep, 2006
1 commit
-
The EDD code would scan the command line as a fixed array, without
taking account of either whitespace, null-termination, the old
command-line protocol, late overrides early, or the fact that the
command line may not be reachable from INITSEG.This should fix those problems, and enable us to use a longer command
line.Signed-off-by: H. Peter Anvin
Signed-off-by: Andi Kleen
01 May, 2005
1 commit
-
The specifications that talk about E820 map doesn't have an upper limit on
the number of e820 entries. But, today's kernel has a hard limit of 32.
With increase in memory size, we are seeing the number of E820 entries
reaching close to 32. Patch below bumps the number upto 128.The patch changes the location of EDDBUF in zero-page (as it comes after E820).
As, EDDBUF is not used by boot loaders, this patch should not have any effect
on bootloader-setup code interface.Patch covers both i386 and x86-64.
Tested on:
* grub booting bzImage
* lilo booting bzImage with EDID info enabled
* pxeboot of bzImageSide-effect:
bss increases by ~ 2K and init.data increases by ~7.5K
on all systems, due to increase in size of static arrays.Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
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!