Well, I am very glad to see all the input on this idea. Lets see if I can add some info and sort what we have.
Current speeds. My current system takes about 3 seconds for Linuxbios, then 2 more for kernel, to the suspend2 code, then 7~12sec depending on how much compression I am using on the suspend2 image. So a total boot time of about 15 seconds. Up and playing music, with full X. A normal boot is 33 sec, to get to a full X + music playing. I want sub 10. Dont care about suspending time, just resume. All this is suspend to disk. I need to be able to power the system off of N time.
Could we make suspend be a hybrid process? Taking both firmware and the OS?
No BIOS call backs, I think we can get away with suspending from the OS, and setting a cmos flag for linuxbios to catch on the way up. This would allow us to just restore the "needed" memory, instead of hibernation mess of windows. So place this such code in filo and boot from swap. (Thanks Guido) Things I dont know. Does Suspend2 replace the kernel? Is it a true full image of RAM? Could we use a version of the suspend2 code for resuming only? Could we use ACPI in order to deal with a call back issue? Make this a power call?
Suspend times VS RAM. In the Suspend2 configs, you can tell it to keep the image size down, and it will place most of the ram in swap before making the image. Thus cutting the boot time way down. Even in the case of larger systems with GB+ of ram. Some idea -Adam
ron minnich wrote:
On 12/11/06, Eric W. Biederman ebiederm@xmission.com wrote:
Suspend to RAM currently appears to be something that the OS cannot do alone. At least because cpu wakeup has to go through the BIOS.
Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS.
we're working on a mostly OS-based approach for OLPC; stay tuned. The handshake with BIOS should be minimal, and require 0 callbacks.
ron