On Thu, 8 Mar 2007 22:45:37 +0100
Manuel Bouyer <bouyer@antioche.eu.org> wrote:

> On Thu, Mar 08, 2007 at 04:34:55PM -0500, Perry E. Metzger wrote:
> > 
> > Manuel Bouyer <bouyer@antioche.eu.org> writes:
> > >> I'll amend that further, and make that suspend to swap.
> > >
> > > I would love this. But it's a way to large projet for SOC.
> > 
> > A framework for hibernation is not too large a project.
> 
> Maybe I'm missing somthing, but to resume from hibernation you'll load
> the kernel as a normal boot, and then restore state from a large file
> (or swap, or whatever). Then you need to be able to restore state of
> various parts of the kernel (sockets, open files, etc ...), which may
> not be at the same address as at hibernation time, because the kernel
> has done some work and rebooted in between. This is the difficult
> part, and may require redesign of large parts of the kernel. But
> maybe there's other way to get at it that I didn't see (doing the
> work from the boot loader ?)

You could do it by writing out all of memory to the swap file,
including the kernel text section.  This would work better, I think,
with a different boot loader design, where the boot loader either
pulled in /netbsd or restored from the hibernate (swap?)
file.  Alternatively you could assert that kernel changes simply
weren't allowed, and compared some magic number in the booted kernel to
that written out in the swap area -- put 16 bytes from /dev/random into
vers.c at kernel build time, for example.
> 
> > Making all
> > drivers capable of freezing/thawing their state probably is (but
> > that's also needed for ACPI S3).
> 
> not as much. for hibernation you also need to restore the software
> state. For S3, hardware state is enough.
> 
Right -- and we've never gotten that working.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb