x86 boot : export boot_params via sysfs

This patch export the boot parameters via sysfs. This can be used for debugging and kexec.

The files added are as follow:

/sys/kernel/boot_params/data : binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version

This patch is based on 2.6.24-rc5-mm1 and has been tested on i386 and x86_64 platoform.

This patch is based on the Peter Anvin's proposal.

v3:

- Use updated API: kobject_create_and_add.

v2:

- Add document in Document/ABI.

---
 Documentation/ABI/testing/sysfs-kernel-boot_params |   14 +++
 arch/x86/kernel/Makefile_32                        |    1 
 arch/x86/kernel/Makefile_64                        |    1 
 arch/x86/kernel/ksysfs.c                           |   88 +++++++++++++++++++++
 arch/x86/kernel/setup64.c                          |    2 
 arch/x86/kernel/setup_32.c                         |    2 
 6 files changed, 106 insertions(+), 2 deletions(-)

@@ -40,6 +40,7 @@ obj-$(CONFIG_X86_VSMP)		+= vsmp_64.o
 obj-$(CONFIG_K8_NB)		+= k8.o
 obj-$(CONFIG_AUDIT)		+= audit_64.o
 obj-$(CONFIG_EFI)		+= efi.o efi_64.o efi_stub_64.o
+obj-$(CONFIG_SYSFS)		+= ksysfs.o
 
 obj-$(CONFIG_MODULES)		+= module_64.o
 obj-$(CONFIG_PCI)		+= early-quirks.o

@@ -24,7 +24,7 @@
 #include <asm/sections.h>
 #include <asm/setup.h>
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;
 

@@ -45,6 +45,7 @@ obj-$(CONFIG_EARLY_PRINTK)	+= early_prin
 obj-$(CONFIG_HPET_TIMER) 	+= hpet.o
 obj-$(CONFIG_K8_NB)		+= k8.o
 obj-$(CONFIG_MGEODE_LX)		+= geode_32.o mfgpt_32.o
+obj-$(CONFIG_SYSFS)		+= ksysfs.o
 
 obj-$(CONFIG_VMI)		+= vmi_32.o vmiclock_32.o
 obj-$(CONFIG_PARAVIRT)		+= paravirt_32.o

@@ -194,7 +194,7 @@ unsigned long saved_videomode;
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 struct edd edd;

@@ -0,0 +1,14 @@
+What:		/sys/kernel/boot_params
+Date:		December 2007
+Contact:	Huang Ying <[email protected]>
+Description:
+		The /sys/kernel/boot_params directory contains two
+		files: "data" and "version". It is used to export the
+		kernel boot parameters of x86 platform to user space
+		for debugging and kexec. The "data" file is the binary
+		representation of struct boot_params. The "version"
+		file is the string representation of boot protocol
+		version.
+
+Users:
+		Kexec Mailing List <[email protected]>

But it ignored the fact that I said I didn't want this binary file in sysfs :)

Please take Eric's suggestion and split it up into the different pieces. Some of the fields can be binary files, as they come directly from the firmware, but the others should be text.

thanks,

greg k-h

But PLEASE include the full structure as a ready-to-eat object. PLEASE.

-hpa

I should clarify this.

By all means go ahead and provide broken-out fields where it makes sense. However:

- this *IS* a structure defined by protocol, and which, for all users except the 16-bit entry, comes from outside the kernel (bootloader or firmware.)

- a newer kernel version can add fields to this structure, but can never remove them. This would cause a potential information loss if the current kernel doesn't have all fields available.

- the binary structure is the format that the majority of users will need.

This is directly analogous to how we treat identity information in IDE, or PCI configuration space -- some fields are pre-digested, but the entire raw information is also available.

-hpa

Add to that a totally unchanged value can just be easier to get correct.

Still the kexec code as much as it can should not look there, as we may get the same basic information in a couple of different ways.

EFI memmap vs. e820 for example. If/when that is the case /sbin/kexec should get the information and spit it out into whatever format makes sense for the destination kernel. My sense is just passing through values is brittleness where we don't want it.

However I think being able to get at the raw boot information overall sounds useful. I just don't know if it is generally useful or just useful when debugging bootloaders though.

Eric

If struct boot_params as a whole is useless for kexec, I can move it to debugfs, because kexec is the only normal user now. Then which fields of struct boot_params do you think is useful for kexec?

Refer to include/asm-x86/bootparam.h

edid_info?
e820_entries and e820_map? maybe useful for kdump
edd related fields (eddbuf, edd_mbr_sig_buffer, etc)? split fields until fundamental types?

Best Regards,
Huang Ying