On Thu, Mar 08, 2007 at 05:00:09PM -0500, Steven M. Bellovin wrote:
> 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.

I was not talking about kernel change itself, just restoring the
kernel's state. If the kernel itself does it you can't just block-copy
from disk to ram. If something else does it - well, what's this
something else ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--