On Mon, 2008-03-24 at 18:05 +0100, Eric Piel wrote: > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
