This patch add a field of 64-bit physical pointer to NULL terminated

single linked list of struct setup_data to real-mode kernel

header. This is used as a more extensible boot parameters passing

mechanism.
This patch has been tested against 2.6.23-rc6-mm1 kernel on x86_64. It

is based on the proposal of Peter Anvin.
Known Issues:
1. Where is safe to place the linked list of setup_data?

Because the length of the linked list of setup_data is variable, it

can not be copied into BSS segment of kernel as that of "zero

page". We must find a safe place for it, where it will not be

overwritten by kernel during booting up. The i386 kernel will

overwrite some pages after _end. The x86_64 kernel will overwrite some

pages from 0x1000 on.
ChangeLog:
-- v2 --
- Increase the boot protocol version number.

- Check version number before parsing setup_data.
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
 arch/i386/Kconfig            |    3 ---

 arch/i386/boot/header.S      |    8 +++++++-

 arch/i386/kernel/setup.c     |   22 ++++++++++++++++++++++

 arch/x86_64/kernel/setup.c   |   21 +++++++++++++++++++++

 include/asm-i386/bootparam.h |   15 +++++++++++++++

 include/asm-i386/io.h        |    7 +++++++

 6 files changed, 72 insertions(+), 4 deletions(-)
Index: linux-2.6.23-rc6/include/asm-i386/bootparam.h

===================================================================

--- linux-2.6.23-rc6.orig/include/asm-i386/bootparam.h	2007-09-19 10:22:02.000000000 +0800

+++ linux-2.6.23-rc6/include/asm-i386/bootparam.h	2007-09-19 16:41:57.000000000 +0800

@@ -9,6 +9,17 @@

 #include <asm/ist.h>

 #include <video/edid.h>
+/* setup data types */

+#define SETUP_NONE			0

+

+/* extensible setup data list node */

+struct setup_data {

+	u64 next;

+	u32 type;

+	u32 len;

+	u8 data[0];

+} __attribute__((packed));

+

 struct setup_header {

 	u8	setup_sects;

 	u16	root_flags;

@@ -41,6 +52,10 @@

 	u32	initrd_addr_max;

 	u32	kernel_alignment;

 	u8	relocatabl...
[ message continues ]

Do you actually need a linked list of data?  This is similar to the

changes to bzImage to support booting bzImage a paravirt environment,

but I just proposed a pointer to a single info structure, along with a

field to identify the boot environment (ie, native/lguest/xen etc).  It

would be easy to extend this to handle EFI as just another boot

environment, and you could hang a list of structures off the pointer.
    J

-

*He* doesn't, but *we* do.  We have already run into at least one case

where the existing structure is insufficient (EDD overhaul), and so we

need to do something extensible.
	-hpa

-

The latter is definitely not safe, since the space below 640K is the

documented place to put the command line (and presumably where the

bootloader would put other auxilliary chunks.)
I'll try to do a full review of this later today.  Haven't had time yet

to look at this anything than but piecemeal.
	-hpa

-

Hi, Peter,
Do you think this patch and the 32-bit boot protocol patch are ready to

merge for -mm? If not, I can revise them.
Best Regards,

Huang Ying

-

Sorry, haven't had a chance to look at it in proper detail yet, mostly

due to debugging, but one thing I'd like to see is both the boot_params

structure as well as all the chained information pointers exported into

sysfs.  The experience with the x86 setup code has shown that it would

help immensely with debugging, not to mention being available to tools

like kexec.
	-hpa

-