Hi

Theoretically, one could dump the system image using ddb, and later, bootin=
g directly to ddb, in which he could load a partition to ram... Of course, =
ddb wouldnt be used for production, but its a quick hack that can be done t=
o illustrate the idea... As for the systemimage > swap-usedswap, one could =
use the already existing "dump" infrastructure... boot on wd0a swap on wd0b=
 dump on wd0e ;) and create a dedicated dump partition that is >=3D physica=
l ram size. this way, swap is untouched.

Then, all one would need for production use is a generalized framework that=
 does something like ddb does... "halts" the kernel, does stuff, "resumes" =
the kernel, even if this implies overwriting ALL the physical ram from the =
disk image (its not that hard to jump to an unused ram area with temporary =
code then return to the kernel, and since that area is unused, it will be e=
ventually wiped anyways)

Anyways, this is from an OUTSIDER point of view. I am a NetBSD enthusiast, =
but I didnt have time to study kernel internals yet. Some terms might not b=
e in optimal shape, and English is not my first language :)=20

Kind Regards
Evaldo Gardenali ("UdontKnow" @ freenode)

----- Original Message -----
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Chuck Swiger <cswiger@mac.com>
Cc: Bucky Katz <bucky@picovex.com>, NetBSD Users's Discussion List <netbsd-=
users@NetBSD.org>
Sent: S=C3=A1bado, 10 de Mar=C3=A7o de 2007 07h00min39s GMT-0200 Auto-Detec=
ted
Subject: Re: SOC project idea

On Fri, Mar 09, 2007 at 01:32:53PM -0800, Chuck Swiger wrote:
> On Mar 9, 2007, at 11:20 AM, Bucky Katz wrote:
> >>An ACPI-aware BIOS may have support for loading the state of RAM
> >>directly from disk, although the preferred method involves the OS
> >>being ACPI-aware and handling the load of RAM from disk itself using
> >>the OS-specific device drivers.  The former approach probably
> >>requires a dedicated partition which the BIOS uses, whereas the
> >>approach using the OS-specific drivers can read and write the state
> >>of memory to a file using whatever native filesystem(s) the OS
> >>itself supports.
> >
> >ACPI is great for PCs, but sucks for embedded systems, which rarely,
> >if ever, have hardware support for ACPI. It would be nice if a
> >framework were able to cope with not relying on ACPI.
>=20
> You have a good point, but if the firmware/BIOS doesn't support ACPI =20
> at least to some extent, how is one going to get the system into a S4 =20
> state?  :-)

You don't need harware support at all: just save the state to disk and
poweroff. When the kernel loads on next power up, restore the state.
I think it's this way that solaris does suspend to disk on sparc
hardware.

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