On Mar 10, 2007, at 2:00 AM, Manuel Bouyer wrote:
>>> 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.
>>
>> You have a good point, but if the firmware/BIOS doesn't support ACPI
>> at least to some extent, how is one going to get the system into a S4
>> state?  :-)
>
> You don't need har[d]ware 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.

*shrug*-- powering off the hardware entirely isn't S4, it's S5.

On the other hand, if the saved image being made lets the system  
reboot and restore the prior context, it will serve the desired  
purpose just as well, regardless of the names used by ACPI.  My  
original point was that there are two approaches, one which relies  
heavily on the OS to support this capability, and one where the BIOS  
or firmware does most of the work and does not require the OS to  
implement suspend-to-disk itself.

I suspect that either Solaris or OS X would make good candidates for  
studying how a platform handles power-management and suspend-to-disk  
on non-Intel/ACPI platforms as well as on x86-compatible hardware.  I  
suspect that trying to get NetBSD with a working suspend-to-disk  
implementation would be most easily done by trying to first solve the  
easier problem-- getting it to work on an ACPI-aware platform which  
does most of the heavy lifting in the firmware-- and then expanding  
NetBSD's capabilities to work on other platforms, but YMMV.

-- 
-Chuck