linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH -mm -v2] x86 boot : export boot_params via sysfs
@ 2007-12-12  8:59 Huang, Ying
  2007-12-12 17:46 ` Greg KH
  0 siblings, 1 reply; 10+ messages in thread
From: Huang, Ying @ 2007-12-12  8:59 UTC (permalink / raw)
  To: Greg KH, akpm, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Andi Kleen, Eric W. Biederman
  Cc: linux-kernel

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-rc4-mm1 and has been tested on i386 and
x86_64 platoform.

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


v2:

- Add document in Document/ABI.


Signed-off-by: Huang Ying <ying.huang@intel.com>

---
 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                           |   89 +++++++++++++++++++++
 arch/x86/kernel/setup64.c                          |    2 
 arch/x86/kernel/setup_32.c                         |    2 
 6 files changed, 107 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/Makefile_64
+++ b/arch/x86/kernel/Makefile_64
@@ -39,6 +39,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
--- a/arch/x86/kernel/setup64.c
+++ b/arch/x86/kernel/setup64.c
@@ -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;
 
--- /dev/null
+++ b/arch/x86/kernel/ksysfs.c
@@ -0,0 +1,89 @@
+/*
+ * Architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ *      Huang Ying <ying.huang@intel.com>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/init.h>
+#include <linux/stat.h>
+#include <linux/mm.h>
+
+#include <asm/setup.h>
+
+static ssize_t boot_params_version_show(struct kobject *kobj,
+					struct kobj_attribute *attr, char *buf)
+{
+	return sprintf(buf, "0x%04x\n", boot_params.hdr.version);
+}
+
+static struct kobj_attribute boot_params_version_attr =
+	__ATTR(version, S_IRUGO, boot_params_version_show, NULL);
+
+static struct attribute *boot_params_attrs[] = {
+	&boot_params_version_attr.attr,
+	NULL
+};
+
+static struct attribute_group boot_params_attr_group = {
+	.attrs = boot_params_attrs,
+};
+
+static ssize_t boot_params_data_read(struct kobject *kobj,
+				     struct bin_attribute *bin_attr,
+				     char *buf, loff_t off, size_t count)
+{
+	memcpy(buf, (void *)&boot_params + off, count);
+	return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+	.attr = {
+		.name = "data",
+		.mode = S_IRUGO,
+	},
+	.read = boot_params_data_read,
+	.size = sizeof(boot_params),
+};
+
+static int __init boot_params_ksysfs_init(void)
+{
+	int error;
+	struct kobject *boot_params_kobj;
+
+	boot_params_kobj = kobject_create_and_register("boot_params",
+						       kernel_kobj);
+	if (!boot_params_kobj) {
+		error = -ENOMEM;
+		goto err_return;
+	}
+	error = sysfs_create_group(boot_params_kobj,
+				   &boot_params_attr_group);
+	if (error)
+		goto err_boot_params_subsys_unregister;
+	error = sysfs_create_bin_file(boot_params_kobj,
+				      &boot_params_data_attr);
+	if (error)
+		goto err_boot_params_subsys_unregister;
+	return 0;
+err_boot_params_subsys_unregister:
+	kobject_unregister(boot_params_kobj);
+err_return:
+	return error;
+}
+
+static int __init arch_ksysfs_init(void)
+{
+	int error;
+
+	error = boot_params_ksysfs_init();
+
+	return error;
+}
+
+arch_initcall(arch_ksysfs_init);
--- a/arch/x86/kernel/Makefile_32
+++ b/arch/x86/kernel/Makefile_32
@@ -44,6 +44,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
--- a/arch/x86/kernel/setup_32.c
+++ b/arch/x86/kernel/setup_32.c
@@ -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;
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-boot_params
@@ -0,0 +1,14 @@
+What:		/sys/kernel/boot_params
+Date:		December 2007
+Contact:	Huang Ying <ying.huang@intel.com>
+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 <kexec@lists.infradead.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12  8:59 [PATCH -mm -v2] x86 boot : export boot_params via sysfs Huang, Ying
@ 2007-12-12 17:46 ` Greg KH
  2007-12-12 17:54   ` H. Peter Anvin
  0 siblings, 1 reply; 10+ messages in thread
From: Greg KH @ 2007-12-12 17:46 UTC (permalink / raw)
  To: Huang, Ying
  Cc: akpm, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

On Wed, Dec 12, 2007 at 04:59:51PM +0800, Huang, Ying wrote:
> 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-rc4-mm1 and has been tested on i386 and
> x86_64 platoform.
> 
> This patch is based on the Peter Anvin's proposal.

As outlined in a previous email, I object to the whole structure being
exported to userspace as a binary blob.  Please change that.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 17:46 ` Greg KH
@ 2007-12-12 17:54   ` H. Peter Anvin
  2007-12-12 18:59     ` Greg KH
  0 siblings, 1 reply; 10+ messages in thread
From: H. Peter Anvin @ 2007-12-12 17:54 UTC (permalink / raw)
  To: Greg KH
  Cc: Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

Greg KH wrote:
> On Wed, Dec 12, 2007 at 04:59:51PM +0800, Huang, Ying wrote:
>> 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-rc4-mm1 and has been tested on i386 and
>> x86_64 platoform.
>>
>> This patch is based on the Peter Anvin's proposal.
> 
> As outlined in a previous email, I object to the whole structure being
> exported to userspace as a binary blob.  Please change that.
> 

I would prefer to have the binary blob available; exported fields is 
possible too, of course.

This is a binary structure defined by protocol; in that way it's not 
significantly different from something passed from the firmware (in 
fact, it might very well *be* passed from the firmware.)  We have in the 
past found platform bugs by looking at the contents of the whole 
structure, e.g. to find that part of it has been inappropriately clobbered.

It is also in the form needed by e.g. kexec to operate.

	-hpa

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 17:54   ` H. Peter Anvin
@ 2007-12-12 18:59     ` Greg KH
  2007-12-12 19:05       ` H. Peter Anvin
  0 siblings, 1 reply; 10+ messages in thread
From: Greg KH @ 2007-12-12 18:59 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

On Wed, Dec 12, 2007 at 09:54:12AM -0800, H. Peter Anvin wrote:
> Greg KH wrote:
>> On Wed, Dec 12, 2007 at 04:59:51PM +0800, Huang, Ying wrote:
>>> 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-rc4-mm1 and has been tested on i386 and
>>> x86_64 platoform.
>>>
>>> This patch is based on the Peter Anvin's proposal.
>> As outlined in a previous email, I object to the whole structure being
>> exported to userspace as a binary blob.  Please change that.
>
> I would prefer to have the binary blob available; exported fields is 
> possible too, of course.
>
> This is a binary structure defined by protocol;

What protocol?  Is this a "standard" documented somewhere?

> in that way it's not significantly different from something passed
> from the firmware (in fact, it might very well *be* passed from the
> firmware.)  We have in the past found platform bugs by looking at the
> contents of the whole structure, e.g.  to find that part of it has
> been inappropriately clobbered.

For debugging things, then just export it through debugfs.

> It is also in the form needed by e.g. kexec to operate.

Does kexec need this today to work properly?  Or is this something new?

What userspace program is going to know the exact data format of this
blob, and where is it going to know that format from?  The kernel header
files in sanitized form?  Or something else?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 18:59     ` Greg KH
@ 2007-12-12 19:05       ` H. Peter Anvin
  2007-12-12 22:21         ` Greg KH
  0 siblings, 1 reply; 10+ messages in thread
From: H. Peter Anvin @ 2007-12-12 19:05 UTC (permalink / raw)
  To: Greg KH
  Cc: Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

Greg KH wrote:
>> This is a binary structure defined by protocol;
> 
> What protocol?  Is this a "standard" documented somewhere?

Yes, see Documentation/i386/* (although some of it is documented by 
reference to include/asm-x86/boot_params.h).

>> in that way it's not significantly different from something passed
>> from the firmware (in fact, it might very well *be* passed from the
>> firmware.)  We have in the past found platform bugs by looking at the
>> contents of the whole structure, e.g.  to find that part of it has
>> been inappropriately clobbered.
> 
> For debugging things, then just export it through debugfs.

Fair enough, however...

>> It is also in the form needed by e.g. kexec to operate.
> 
> Does kexec need this today to work properly?  Or is this something new?

I believe kexec currently tries to reconstitute it from what data is 
available to it.  This is incomplete, though, and has been flagged as a 
problem for kexec.

> What userspace program is going to know the exact data format of this
> blob, and where is it going to know that format from?  The kernel header
> files in sanitized form?  Or something else?

It can pick it up from <asm/boot_params.h> (which is now 
userspace-safe); or it can decode it itself.  Programs like kexec can 
pass through most of the data without examining it, this is the main 
reason for having it as a blob.

	-hpa

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 19:05       ` H. Peter Anvin
@ 2007-12-12 22:21         ` Greg KH
  2007-12-12 22:37           ` H. Peter Anvin
                             ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Greg KH @ 2007-12-12 22:21 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
> Greg KH wrote:
>>> This is a binary structure defined by protocol;
>> What protocol?  Is this a "standard" documented somewhere?
>
> Yes, see Documentation/i386/* (although some of it is documented by 
> reference to include/asm-x86/boot_params.h).

Ah, so the structure has changed over the years, making this not so much
a "firmware" field as originally thought :)

>>> in that way it's not significantly different from something passed
>>> from the firmware (in fact, it might very well *be* passed from the
>>> firmware.)  We have in the past found platform bugs by looking at the
>>> contents of the whole structure, e.g.  to find that part of it has
>>> been inappropriately clobbered.
>> For debugging things, then just export it through debugfs.
>
> Fair enough, however...
>
>>> It is also in the form needed by e.g. kexec to operate.
>> Does kexec need this today to work properly?  Or is this something new?
>
> I believe kexec currently tries to reconstitute it from what data is 
> available to it.  This is incomplete, though, and has been flagged as a 
> problem for kexec.

Can't kexec get this from within the kernel itself when it is running?
It doesn't need to get this from userspace, does it?

>> What userspace program is going to know the exact data format of this
>> blob, and where is it going to know that format from?  The kernel header
>> files in sanitized form?  Or something else?
>
> It can pick it up from <asm/boot_params.h> (which is now userspace-safe); 
> or it can decode it itself.  Programs like kexec can pass through most of 
> the data without examining it, this is the main reason for having it as a 
> blob.

I just don't want kernel structures exported in binary fashions in
sysfs.  If there are specific portions that kexec currently can't figure
out, why not just export those fields?

And, by exporting the different fields (yeah, lots of files, no big
deal), you can handle the change in the structure over time much easier
than trying to "know" the layout of the binary blob.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 22:21         ` Greg KH
@ 2007-12-12 22:37           ` H. Peter Anvin
  2007-12-12 22:43           ` Randy Dunlap
  2007-12-12 22:52           ` Eric W. Biederman
  2 siblings, 0 replies; 10+ messages in thread
From: H. Peter Anvin @ 2007-12-12 22:37 UTC (permalink / raw)
  To: Greg KH
  Cc: Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar, Andi Kleen,
	Eric W. Biederman, linux-kernel

Greg KH wrote:
> On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
>> Greg KH wrote:
>>>> This is a binary structure defined by protocol;
>>> What protocol?  Is this a "standard" documented somewhere?
>> Yes, see Documentation/i386/* (although some of it is documented by 
>> reference to include/asm-x86/boot_params.h).
> 
> Ah, so the structure has changed over the years, making this not so much
> a "firmware" field as originally thought :)

The structure has been *amended* to over the years.  That's why the 
format is so awkward...

>>>> in that way it's not significantly different from something passed
>>>> from the firmware (in fact, it might very well *be* passed from the
>>>> firmware.)  We have in the past found platform bugs by looking at the
>>>> contents of the whole structure, e.g.  to find that part of it has
>>>> been inappropriately clobbered.
>>> For debugging things, then just export it through debugfs.
>> Fair enough, however...
>>
>>>> It is also in the form needed by e.g. kexec to operate.
>>> Does kexec need this today to work properly?  Or is this something new?
>> I believe kexec currently tries to reconstitute it from what data is 
>> available to it.  This is incomplete, though, and has been flagged as a 
>> problem for kexec.
> 
> Can't kexec get this from within the kernel itself when it is running?
> It doesn't need to get this from userspace, does it?

It probably could, but it probably needs to modify some fields.

>>> What userspace program is going to know the exact data format of this
>>> blob, and where is it going to know that format from?  The kernel header
>>> files in sanitized form?  Or something else?
>> It can pick it up from <asm/boot_params.h> (which is now userspace-safe); 
>> or it can decode it itself.  Programs like kexec can pass through most of 
>> the data without examining it, this is the main reason for having it as a 
>> blob.
> 
> I just don't want kernel structures exported in binary fashions in
> sysfs.  If there are specific portions that kexec currently can't figure
> out, why not just export those fields?
> 
> And, by exporting the different fields (yeah, lots of files, no big
> deal), you can handle the change in the structure over time much easier
> than trying to "know" the layout of the binary blob.

But if you kexec an older kernel from a newer kernel, the potential 
additional information will be lost for a subsequent uprevision kexec, 
for example.

	-hpa


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 22:21         ` Greg KH
  2007-12-12 22:37           ` H. Peter Anvin
@ 2007-12-12 22:43           ` Randy Dunlap
  2007-12-12 23:08             ` Eric W. Biederman
  2007-12-12 22:52           ` Eric W. Biederman
  2 siblings, 1 reply; 10+ messages in thread
From: Randy Dunlap @ 2007-12-12 22:43 UTC (permalink / raw)
  To: Greg KH
  Cc: H. Peter Anvin, Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar,
	Andi Kleen, Eric W. Biederman, linux-kernel

On Wed, 12 Dec 2007 14:21:46 -0800 Greg KH wrote:

> On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
> > Greg KH wrote:
> >>> This is a binary structure defined by protocol;
> >> What protocol?  Is this a "standard" documented somewhere?
> >
> > Yes, see Documentation/i386/* (although some of it is documented by 
> > reference to include/asm-x86/boot_params.h).
> 
> Ah, so the structure has changed over the years, making this not so much
> a "firmware" field as originally thought :)
> 
> >>> in that way it's not significantly different from something passed
> >>> from the firmware (in fact, it might very well *be* passed from the
> >>> firmware.)  We have in the past found platform bugs by looking at the
> >>> contents of the whole structure, e.g.  to find that part of it has
> >>> been inappropriately clobbered.
> >> For debugging things, then just export it through debugfs.
> >
> > Fair enough, however...
> >
> >>> It is also in the form needed by e.g. kexec to operate.
> >> Does kexec need this today to work properly?  Or is this something new?
> >
> > I believe kexec currently tries to reconstitute it from what data is 
> > available to it.  This is incomplete, though, and has been flagged as a 
> > problem for kexec.
> 
> Can't kexec get this from within the kernel itself when it is running?
> It doesn't need to get this from userspace, does it?

I don't know if this patch is trying to solve this (->) problem, but there
is a desire for drivers to have a decent way to tell if the kernel that
is executing is a kexec/crash kernel or not.  If it is a kexec/crash
kernel, then (some) drivers may not allocate as many buffers as they
normally do, since the kernel would likely be configured to use
less memory.  The solution doesn't have to involve sysfs .. or it could.


> >> What userspace program is going to know the exact data format of this
> >> blob, and where is it going to know that format from?  The kernel header
> >> files in sanitized form?  Or something else?
> >
> > It can pick it up from <asm/boot_params.h> (which is now userspace-safe); 
> > or it can decode it itself.  Programs like kexec can pass through most of 
> > the data without examining it, this is the main reason for having it as a 
> > blob.
> 
> I just don't want kernel structures exported in binary fashions in
> sysfs.  If there are specific portions that kexec currently can't figure
> out, why not just export those fields?
> 
> And, by exporting the different fields (yeah, lots of files, no big
> deal), you can handle the change in the structure over time much easier
> than trying to "know" the layout of the binary blob.

---
~Randy

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 22:21         ` Greg KH
  2007-12-12 22:37           ` H. Peter Anvin
  2007-12-12 22:43           ` Randy Dunlap
@ 2007-12-12 22:52           ` Eric W. Biederman
  2 siblings, 0 replies; 10+ messages in thread
From: Eric W. Biederman @ 2007-12-12 22:52 UTC (permalink / raw)
  To: Greg KH
  Cc: H. Peter Anvin, Huang, Ying, akpm, Thomas Gleixner, Ingo Molnar,
	Andi Kleen, linux-kernel, Kexec Mailing List

Greg KH <greg@kroah.com> writes:

> On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
>> Greg KH wrote:
>>>> This is a binary structure defined by protocol;
>>> What protocol?  Is this a "standard" documented somewhere?
>>
>> Yes, see Documentation/i386/* (although some of it is documented by 
>> reference to include/asm-x86/boot_params.h).
>
> Ah, so the structure has changed over the years, making this not so much
> a "firmware" field as originally thought :)

The structure has grown and fields have been added in a backwards
compatible way.  It is very much an ABI from the bootloader to the
kernel.

>> I believe kexec currently tries to reconstitute it from what data is 
>> available to it.  This is incomplete, though, and has been flagged as a 
>> problem for kexec.
>
> Can't kexec get this from within the kernel itself when it is running?
> It doesn't need to get this from userspace, does it?

/proc/kmem?  All of this work happens in user space.  The kexec
syscall interface is just load these chunks of data at this these
addresses and finally jump to this address.

All of the interesting kexec work happens in user space, and it needs
to stay that way.  Otherwise we loose the flexibility and simplicity
on the kernel side.

>> It can pick it up from <asm/boot_params.h> (which is now userspace-safe); 
>> or it can decode it itself.  Programs like kexec can pass through most of 
>> the data without examining it, this is the main reason for having it as a 
>> blob.
>
> I just don't want kernel structures exported in binary fashions in
> sysfs.  If there are specific portions that kexec currently can't figure
> out, why not just export those fields?

So all of the fields are binary.
The entire structure is binary.
The native format is binary.

So either we need to export the processed and chewed up version of the
information like we do today in /proc/iomem.  Or we need to export the
raw binary format.

> And, by exporting the different fields (yeah, lots of files, no big
> deal), you can handle the change in the structure over time much easier
> than trying to "know" the layout of the binary blob.

Well /sbin/kexec fundamentally has to "know" the layout of that binary
blob because it generates it and hands it to the kernel.

Greg I think I am with you on this one.  If something other then
/sbin/kexec is going to use that information we need to split it
by field, although I expect the fields to remain binary.  Things
like the e820 memory map and most of the other fields are binary
structures defined to be returned by the firmware so at that level
we have extremely well defined binary blobs, that may possibly
be used for other things.

/sbin/kexec needs to retain the ability to parse and understand the
information because frequently it needs to change little things like
the memory map and the command line and possibly other things so it
can't blindly pass this information through.

Eric

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs
  2007-12-12 22:43           ` Randy Dunlap
@ 2007-12-12 23:08             ` Eric W. Biederman
  0 siblings, 0 replies; 10+ messages in thread
From: Eric W. Biederman @ 2007-12-12 23:08 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Greg KH, H. Peter Anvin, Huang, Ying, akpm, Thomas Gleixner,
	Ingo Molnar, Andi Kleen, linux-kernel

Randy Dunlap <randy.dunlap@oracle.com> writes:

> I don't know if this patch is trying to solve this (->) problem, but there
> is a desire for drivers to have a decent way to tell if the kernel that
> is executing is a kexec/crash kernel or not.  If it is a kexec/crash
> kernel, then (some) drivers may not allocate as many buffers as they
> normally do, since the kernel would likely be configured to use
> less memory.  The solution doesn't have to involve sysfs .. or it could.

The patch is trying to make it easier to observe new fields passed to
the kernel by the bootloader in user space.

The drivers should have a way to look at the amount of memory the
kernel is configured to use and operate on that.  I expect this is a
general embedded scenario.

I don't think I have seen a driver concern in the kdump environment
that is unique to that environment.  So in general I figure we should
use whatever it is that is different about the kdump environment that
the causes the drivers to want to do something differently, so the
changes can ideally support more people.

Eric

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2007-12-12 23:11 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-12  8:59 [PATCH -mm -v2] x86 boot : export boot_params via sysfs Huang, Ying
2007-12-12 17:46 ` Greg KH
2007-12-12 17:54   ` H. Peter Anvin
2007-12-12 18:59     ` Greg KH
2007-12-12 19:05       ` H. Peter Anvin
2007-12-12 22:21         ` Greg KH
2007-12-12 22:37           ` H. Peter Anvin
2007-12-12 22:43           ` Randy Dunlap
2007-12-12 23:08             ` Eric W. Biederman
2007-12-12 22:52           ` Eric W. Biederman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).