At this point, all you have to do is to restore the hardware state, which may (or may not) be just the same as recovering from suspend state.
One could flush disk cache, but this is not strictly necessary, as this cache will come back together in the wakeup.
Pending interrupts are a problem, but I think they could be handled just like in the suspend state.
In other words, I think of a full system hibernation as a procedure like this:
1.1) Reserve some memory to allow space for /boot/loader in the return (could be always reserved?)
1.2) Start suspend procedures, leaving only the hibernation device alive
1.3) Set a flag in the loader area to say we are shutting down
1.3) Dump all memory to the hibernation device
1.4) If the loader flag is "shutdown", power off the system
1.5) If the loader flag is "wakeup", go to suspend return procedures
The restore/wakeup is like this:
2.1) /boot/loader detects the hibernation device contains valid data
2.2) Clear the shutdown flag
2.3) Instead of loading the kernel, start loading the hibernation device into memory
2.4) Now, do a "return from suspend" into 1.4)
It's dumb, but it's easier this way. Now one only have to deal with hardware state.
Matthew Dillon wrote:
I think this is doable but not universal. A kernel core dump can't be
used for that sort of thing (it overwrites swap and swap might contain
portions of the user processes in it).
The kernel would have to write out a special save-to-disk file containing the VM image, file handles, signal state, register set, and so forth for each process in the system. Basically it would need to take DragonFly's checkpointing code (as a basis), extend it suitably, and use it to dump each process.
Additional state would also have to be saved.... bound UDP sockets and sockets in a LISTEN state would have to be saved and restored. This is doable.
But the following is far more difficult:
* tty associations - restore * tty state - restore * job control and process group state - restore * open pipes - restore * open fifos - restore * open socketpairs - restore * established connections - throw away
And this is very difficult:
* X windows state, established connections to X from applications, and so forth. However, it might be possible to quiece X out of its video mode, remap the framebuffer, and then switch back into it. But it would still be a nasty problem.
-
Also, it could take just as long to restore the mess as it would just to reboot normally and restart your applications. After all, the system is likely to be disk-bound either way.
-Matt
Matthew Dillon <[EMAIL PROTECTED]>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Jonny
-- Jo�o Carlos Mendes Lu�s - Networking Engineer - [EMAIL PROTECTED] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
