I figured I'd throw this idea out, since although it is not perfect, it
has the potential to elegantly solve a lot of issues with hibernate.
Just as kexec can now be used to write a crashdump after a kernel panic,
a fresh kexec-loaded kernel (loaded into unused memory) could be used to
write the hibernate image of the existing kernel to disk, and then power
off the system (or suspend to ram, or anything else). This avoids the
need for the original kernel to jump through hoops to hibernate itself
in place.
A hibernate sequence would be approximately as follows:
1. Free some memory if needed or desired, and disable the swap device
if it is going to be used to write the hibernate image.
2. Load the fresh kernel in a chunk of available (possibly
pre-allocated) memory (there must also be enough available memory
for this kernel to use).
3. Disable interrupts and stop all devices.
4. Jump to the new kernel, passing whatever state information will be
needed by it to know how to write the image.
5. The new kernel loads, and then either kernel space or user space
writes the necessary data from the old kernel to disk.
6. The new kernel either powers off or suspends to ram. If it suspends
to ram, then it would need to be able to jump back to the old kernel
when it resumes from ram.
The advantages of this approach include:
- having a completely functional system (with a completely functional
userspace) from which the image is written, without having to worry
about messing up the state that is being saved (hell, the user could
even do it via an interactive shell on the new kernel);
- no need to worry about trying to use drivers while some processes are
frozen;
- no need for complicated process freezing; the same logic that can be
used for suspend to ram should be sufficient;
- no need for an atomic copy of memory, or any other complicated memory
copying; the memory of the old kernel, including the page cache, can
be written directly;
- instead of needing a significant amount of free memory to store the
atomic copy, only a few megabytes would needed to load and run the
new kernel.
It may or may not be necessary to require that the new kernel used to
write the image is the same as the existing kernel; it will likely be
useful to require that it is built from the same sources and with a
similar config. It would likely be useful, however, to either compile
out or (e.g. via the kernel command-line) disable the initialization of
drivers that will not be needed to write the image, such as sound
drivers, cdrom drivers, filesystems, and network drivers (if the image
is not to be written via the network).
Of course, if special initialization was needed under the original
kernel to set up the devices that will be used to write the image, such
as device mapper setup, or network initialization, that will have to be
repeated under the new kernel as well. This is the principal
disadvantage to this approach, but since it must be done during resume
from hibernation in any case, it doesn't seem like a very significant
disadvantage. The other disadvantage is that there would be the
delay of loading the fresh kernel; this may, however, only take a second
or two, which is relatively insignificant compared to the time required
to actually write the image, and the delay could be reduced by stripping
out unnecessary drivers from the image-writing kernel.
--
Jeremy Maitin-Shepard
-
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]
