On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
remember release early, release often (with something that functions)
fo rthe current stage where we are trying to make things work don't worry
about packaging everything tight with initrd and re-useing partitions or
kernel images. once everything is working reliably then it's time to look
at useing the same kernel for multiple functions, writing to a partition
that's i use for other things, etc
I don't agree. You need to think of many limitations in advance, because
they need to be taken into consideration in the design.
Otherwise we'll end up with something that will need to be bandaided like the
freezer. :-)
on the other hand, worrying about all the possible ways to do things can
paralize you.
the big advantage of the kexec approach is that the new userspace that's
setup with the new kernel can do _anything_.
No, it can't. For example, it can't access filesystems mounted by the
hibernated kernel, or they may get corrupted after the restore (if they are
journaling, it can't even read from them).
it's only ext3 that has this bug when mounting a fileystem read-only
AFAIK.
Which reminds me of one more issue, which is that the image-saving kernel
won't be able to use these filesystems either, so its modules and user space
will have to be available from somewhere else (like a RAM disk or dedicated
partition). So things get ugly.
another reason to go ahead and make a dedicated no-module kernel for the
hibernate phase ;-)
Apart from this, the new kernel's user space cannot blindly modify swap space
that might be in use by the hibernated kernel.
with swap space you have two options
1. free it up (to a swap file if needed) and don't worry about it
2. try and ensure that nothing else on the system attempts to use the swap
partition until you reboot.
#2 is failure prone, #1 would be more reliable.
David Lang
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
