Implementing 'Software suspend in FreeBSD' as a final year project.

[Nate Lawson]

Pranav Peshwe wrote:
>             Thanks to the replies and the information
> provided, we have finally decided to implement 'Software 
> Suspend(S4OS) on the FreeBSD Operating System' as our final 
> year project.
> 
>         We have worked with the linux kernel but not that much 
> with the FBSD one.So,currently we do not have much knowledge
> about the FBSD kernel.
> Can we get any pointers as to, where we should start
> from ? and which kernel subsystems will be of particular importance
> to us.Also, which version of FBSD should we preferably use ?
> 
>     Any links for reading would be of immense help.We currently have for 
> reference,the book 'The Design and Implementation of the FreeBSD(v5.2)
> Operating System' - Marshall Kirk McKusick, George V. Neville-Neil 

I'm glad someone is taking a cut at this.  It is a somewhat difficult 
task you are taking on so I hope you are prepared.

1. Read the suspend/resume sections (S4 in particular) of the ACPI spec: 
  http://acpi.info

2. Review the source code and email list archives for Linux software 
suspend 2:  http://www.suspend2.net

There are two means of achieving this.  S4 requires ACPI while software 
suspend does not.  You should implement the latter first since it is 
useful on non-x86 platforms and without ACPI.  S4 depends on a working 
software suspend anyway.

First, your goal is to get the system suspended to an image on disk. 
One easy way to do this is to overload the kernel dump system to write 
the system image to swap.  Relevant source is here:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/kern/kern_shutdown.c?rev=1.176
The dumpsys() function calls a device-specific callback to perform the 
actual dump (i.e. sys/dev/ata, addump()).  The call is this:
	error = (*devsw(dumpdev)->d_dump)(dumpdev);
This dump function has to run in polled mode with interrupts disabled. 
You need to add code to dump userspace as well as kernel space, 
otherwise resume is not very useful.  Also, you need to call the root 
DEVICE_SUSPEND() routine so that all devices will save their state.

After you can generate a full image, the next step is resuming.  You 
should use a different signature in the header of the saved image than 
the one used for kernel core dumps.  For testing purposes, you may want 
a separate swap partition enabled separately so you can still do core 
dumps to debug your suspend code.

Next, update the loader(8) to look for this signature in the swap file 
and load it at the same place as it was saved.  Then, jump into an 
exported disk_resume() routine that calls DEVICE_RESUME() and then 
continues running.  I'm a little unclear of all the initialization that 
needs to occur but you at least have to set up protected mode and a few 
other things that normal init performs without doing the full boot process.

The most likely bug you'll run into in all this is devices that don't 
behave well when resumed this way.  For instance, I believe the apic 
device does different initialization in its startup routine versus its 
resume routine.  To avoid problems, test on the most minimally 
configured system you can.

This should be enough to get you started.  Feel free to post progress 
reports and questions here.

-- 
Nate