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).
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.
Apart from this, the new kernel's user space cannot blindly modify swap space
that might be in use by the hibernated kernel.