To make sure that the swap data won't get clobbered by the writing of
the image, if the swap device is to be used to write the hibernate
image. Presumably something similar is already done. In any case this
is not an important point.
It seems like support for this is mostly already in place though, and it
needs to be done for suspend to ram, kexec, and shutdown anyway.
Just before jumping into the new kernel, with interrupts disabled, the
old kernel could either prepare a data structure that specifies what
pages are allocated, or alternatively simply provide a pointer to the
relevant data structure in the old kernel. I can't say exactly how this
data would be given to the new kernel, but I can't imagine it being
difficult. (For instance, multiboot headers, the kernel command line,
initrd, or some other mechanism could be used.)
Yes. That would be done, as normal, when the kernel loads. Currently
devices are suspended or stopped anyway before the atomic copy, and then
reinitialized to write the image. In theory, this stopping shouldn't be
needed, and I mentioned that if additional support were added to some
drivers for passing some information about the current state of the
device, the device might only need to be partially shut down before
jumping to the new kernel. This might allow, for instance, avoiding
spinning down and then up again the disks.
This would be handled in effectively the same way as if the user wants
to suspend to ram after writing the image: it would be necessary to jump
back to the old kernel. This would effectively be handled in the same
way as a resume, except that the copying back of memory would be
avoided. Presumably the image writing kernel would have devices in
approximately the same state as the image loading kernel, and so the old
kernel needs to be prepared to receive the devices in that state anyway.
The point is, with this kexec approach, essentially no code at all runs
under the old kernel after the very initial steps of the hibernation
have begun, but any code, kernel or user, can run under the new kernel,
because the new kernel provides a completely functional system, while at
the same time not clobbering any of the memory of the old kernel. In
particular, it will be possible to write the image to a fuse file
system.
I think given all of the issues about whether to freeze kernel or users
tasks, which tasks to freeze, etc., it is hard to argue that there are
not complications, and many possible bugs and deadlocks. Linus made the
point that trying to freeze certain things and then continue using some
of the devices is fundamentally broken, because the freezer doesn't know
anything about dependencies.
They could use the same kernel; it would simply be slower. The
distributions could perhaps help with this. If kernel command line
parameters could be used to disable certain subsystems, that should be
relatively easy for users.
The "resume kernel" would be loaded at the same address as the "save
kernel" was loaded (it should probably be the same kernel), and then
have it copy back the image completely without any need for atomic
copies. It can then place the devices in the desired state, and jump to
it. The old kernel would then do what it needs to do with the devices,
and start running things again.
Presumably it would be most convenient to have the normal boot loader
load the resume kernel directly at the desired address. The
disadvantage is that at the same time the image is written, something
would have to be done so that the boot loader would know to load the
resume kernel, rather than the normal kernel. (E.g. the image writing
kernel would need to modify the grub config file.) This shouldn't be a
significant problem in practice.
If resume fails, the resume kernel could just print an error message.
The user would be forced to manually tell the boot loader to not load
the resume kernel (perhaps by selecting a non-default menu option).
Alternatively, the resume kernel could just initialize all devices and
load the system as normal (this won't be possible if the resume kernel
was compiled with certain device support not needed for suspending
removed, though), or kexec another kernel.
It shouldn't matter too much how convenient it is when resume from
hibernate fails, because that shouldn't happen very often anyway.
--
Jeremy Maitin-Shepard
-
