[PATCH -mm -v2] x86 boot : export boot_params via sysfs

[Eric W. Biederman]

Greg KH <greg at 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