On Fri, Nov 15, 2002 at 11:37:07AM -0300, Werner Almesberger wrote:
> Suparna Bhattacharya wrote:
> > What would be best way to pass a parameter or address from the
> > current kernel to kernel being booted (e.g log buffer address
> > or crash dump buffer etc) ?
>
> At the moment, perhaps the initrd mechanism might be a useful
> interface for this. You'd just leave some space either at the
> beginning or at the end of the real initrd (if there's one),
> and put your data there.
>
> Afterwards, you can extract it either from the kernel, or even
> from user space through /dev/initrd (with "noinitrd")
>
> Advantages:
> - fairly non-intrusive
> - (almost ?) all platforms support this way of handling "some
> object in memory"
> - easy to play with from user space
>
> Drawbacks:
> - needs synchronization with existing uses of initrd
> - a bit hackish
>
> I'd expect that there will be eventually a number of things that
> get passed from old to new kernels (e.g. crash data, device scan
> results, etc.), so it may be useful to delay designing a "clean"
> interface (for this, I expect some TLV structure in the initrd
> area would make most sense) until more of those things have
> shown up.
Yes indeed. At the moment however I was just looking at something
as simple as a single (or more) parameter to pass from an old
kernel to the new one. That parameter could be a scalar value/
variable or denote the address of a control block, or something
requiring more complicated interpretation like you mention.
If the parameter is a pointer to an address block right now the
code to put it in a place that doesn't get overwritten when the
new kernel loads is left as the responsibility of the caller.
Designing a generic and clean interface for that would require
more thought and is best delayed a bit till we understand all the
needs better. Mcore for example (as you probably know already)
passes a map of affected pages to the new kernel and during early
bootmem initialization those pages (from the previous boot) are
marked as reserved, instead of moving them to a contiguous memory
area. Its just the start of the map (crash header) that's still
passed in as a fixed location (rather its relative to the end of
the current image) and I was looking at a nice way to avoid that.
One way of course is to add a kernel parameter(s) and set this
through user-space (after extracting it from the
kernel .. possibly via kmem) when loading the image (kexec tools
does all the work of filling up the parameter block). Probably
that's what was intended.
Eric, Is that correct ? BTW, did you have an option (or plan
to add one) in kexec tools to use the current kernel's parameters
and append additional options to it ?
Regards
Suparna
>
> - Werner
>
> --
> _________________________________________________________________________
> / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
> /_http://www.almesberger.net/____________________________________________/
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:31 EST