On Mon, 16 Jul 2007, Al Boldi wrote:
[email protected] wrote:
suspend-to-RAM should not involve kexec, the only reason for doing the
kexec to to get a seperate userspace to use for suspend-to-disk operations
instead of trying to partially freeze the sustem and keep useing it.
Or you could do suspend-to-disk-and-RAM. But in the above case, it was meant
to test kexec compatibility with device suspend/resume calls.
the point I am trying to make here is that there is no reason that the
kexec approach needs to do _any_ suspend/resume calls.
all that is needed is the ability of the new kernel to initialize the
devices it needs.
suspend-to-disk-and-ram could be implemented as three
seperate steps
1. suspend-to-disk
2. resume-from-disk
3. suspend-to-ram
followed by either
4. resume-from-ram
or
4. battery dies and loptop powers off completely
5. power-on boot.
6. resume-from-disk
all that you need to do is to make sure that the system doesn't run
anything that would affect permanent media or the outside world between
steps #2 and #3
yes it's more steps, but each step is logicly seperate, and each step will
be excercised on a regular basis, so the combination of the steps will
also be reliable.
this is far better then creating yet another way to pause the system that
only a few people will use.
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]
