Messages in this thread | | | Date | Wed, 12 Dec 2007 14:37:41 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH -mm -v2] x86 boot : export boot_params via sysfs |
| |
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
| |