On Mon, 2008-03-24 at 18:05 +0100, Eric Piel wrote:
quoted text
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image > 
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm 
> and fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is 
> called. It detects that the special place in the RAM for a new DSDT is 
> used. It provides this pointer to ACPI as the new place to read the DSDT.
> 
> Dave, am I correctly understanding the scenario you had in mind?

Yeah, that's basically what I was thinking.

But, this is only for a case where we can't do the real runtime
replacement that Linus has been advocating.  That approach is clearly
superior, but I would imagine that it'll require some serious ACPI
surgery and won't cover things like if the SRAT table was messed up.

quoted text
> I have pratically no knowledge of kexec. Is there a documented way to 
> pass big chunk of data from one kernel to another one? How can I do that?

Heh.  Documented, no.  What OS do you think this is? ;)  I'm not sure it
has ever been really needed before.  

At one point, kexec just make a copy of the e820 table to tell the new
kernel where it's ram was.  If you carved out a chunk of memory and set
it as reserved, the new kernel could go looking there.

kexec is Eric Biederman's (on cc) baby, and he might have some more
concrete suggestions for you.

-- Dave

--
unsubscribe notice
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/