![]() | |||||||||||||
Messages in this thread |
On Mon, 16 Jul 2007, Al Boldi wrote: > > david@lang.hm 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-07-16 08:59 [from the cache] ©2003-2008 | |||||||||||||