On Mar 8, 2007, at 2:07 PM, Manuel Bouyer wrote:
[ ... ]
> 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 ?

An ACPI-aware BIOS may have support for loading the state of RAM =20
directly from disk, although the preferred method involves the OS =20
being ACPI-aware and handling the load of RAM from disk itself using =20
the OS-specific device drivers.  The former approach probably =20
requires a dedicated partition which the BIOS uses, whereas the =20
approach using the OS-specific drivers can read and write the state =20
of memory to a file using whatever native filesystem(s) the OS itself =20=

supports.

Please see pg 251 of the ACPI spec (http://www.acpi.info/DOWNLOADS/=20
ACPIspec30b.pdf):

"7.3.4.5   System \_S4 State
While the system is in this state, it is in the system S4 sleeping =20
state. The state is logically lower than the
S3 state and is assumed to conserve more power. The behavior of this =20
state is defined as follows:

=95 The processors are not executing instructions. The processor-=20
complex context is not maintained.
=95 DRAM context is not maintained.
=95 Power Resources are in a state compatible with the system S4 state. =20=

All Power Resources that supply a
System-Level reference of S0, S1, S2, or S3 are in the OFF state.
=95 Devices states are compatible with the current Power Resource =20
states. In other words, all devices are in
the D3 state when the system state is S4.
=95 Devices that are enabled to wake the system and that can do so from =20=

their device state in S4 can initiate
a hardware event that transitions the system state to S0. This =20
transition causes the processor to begin
execution at its boot location.

After OSPM has executed the _PTS control method and has put the =20
entire system state into main memory,
there are two ways that OSPM may handle the next phase of the S4 =20
state transition; saving and restoring
main memory. The first way is to use the operating system=92s drivers =20=

to access the disks and file system
structures to save a copy of memory to disk and then initiate the =20
hardware S4 sequence by setting the
SLP_EN register bit. When the system wakes, the firmware performs a =20
normal boot process and transfers
control to the OS via the firmware_waking_vector loader. The OS then =20
restores the system=92s memory and
resumes execution.

The alternate method for entering the S4 state is to utilize the BIOS =20=

via the S4BIOS transition. The BIOS
uses firmware to save a copy of memory to disk and then initiates the =20=

hardware S4 sequence. When the
system wakes, the firmware restores memory from disk and wakes OSPM =20
by transferring control to the
FACS waking vector.

The S4BIOS transition is optional, but any system that supports this =20
mechanism must support entering the
S4 state via the direct OS mechanism. Thus the preferred mechanism =20
for S4 support is the direct OS
mechanism as it provides broader platform support. The alternate =20
S4BIOS transition provides a way to
achieve S4 support on operating systems that do not have support for =20
the direct method."

--=20
-Chuck