On Thu, 12 Jul 2007, Eric W. Biederman wrote:
2. Do not reserve memory for kexec kernel. That is, backup needed memory
before kexec and restore them after kexec.
3. Support the in-place kexec? The relocatable kernel is not necessary
if this can be implemented.
It sounds like what you really want is the normal kexec path enhanced
so that you can return to the kernel you started with.
The normal kexec path already knows how to do the memory shuffle so
it can do on demand memory allocation. That code just needs to
enhanced slightly so that you allocate an extra page, setup an inverse
scatter gather list for restoring the pages, and teach relocate_kernel.S
to preserve it's destination pages by using the inverse scatter gather
list.
The normal kexec path already calls device_shutdown and the like to
stop devices from running. Although again that code path is not
prepared to restore the devices.
we shouldn't need a restore code path if the new kernel re-detects
everything. if kexec already shuts down all the devices we may not need to
implement anything new here (although there may be room for future
performance optimization)
...
For prototyping I would:
- reserve a chunk of memory (possibly with the crashkernel= option)
and run a relocatable kernel out of it.
By using the normal kexec you can boot a relocatable restore kernel
in that reserved region. It is an extra step but it makes things
work today.
- I would use the normal sys_kexec_load.
- I would debug/tweak the user space and the code to reenter the
old kernel. I.e. the device driver stop/start code.
Once it was basically working I would the update normal kexec
memory copy code in relocate.S to preserve the destination pages.
for prototyping there's no need to use the same kernel.
4. Image writing/reading. (Only user space application is needed).
And possibly a few fixes to /dev/mem. This is pretty much the same
process as generating a core dump so there should be some synergy with that.
what fixes are you thinking of?
you are makeing this sound very simple ;-)
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
