diff options
| author | Ot ten Thije <ottenthije@google.com> | 2010-09-20 10:29:22 +0100 |
|---|---|---|
| committer | Ot ten Thije <ottenthije@google.com> | 2010-10-14 16:20:03 +0100 |
| commit | 871da2aa80687142bec00ef7c1112253c76c32bb (patch) | |
| tree | 02e55b1f236f63516c13b47e1b68b092b400f390 /docs | |
| parent | bd62acb45d0199940f3baecfa288a2173e4428ae (diff) | |
| download | external_qemu-871da2aa80687142bec00ef7c1112253c76c32bb.zip external_qemu-871da2aa80687142bec00ef7c1112253c76c32bb.tar.gz external_qemu-871da2aa80687142bec00ef7c1112253c76c32bb.tar.bz2 | |
Added state snapshot support for QemuD.
With this patch, both modem and sensor functionality are correctly
restored when a state snapshot is loaded. This was not the case
previously because communication with either of these services is
done using the qemud daemon, which did not support snapshots.
The boot-properties and charpipe services have no specific save/load
functionality yet, since the framework itself should be reviewed
first. Adding support for bootproperties should not be difficult
though, and charpipe may not need it.
For a description of the high-level process for saving and loading,
consult section IV "State snapshots" in docs/ANDROID-QEMUD.TXT.
Change-Id: I5b06d88b911ca096e78060163174904c48a01c66
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ANDROID-QEMUD.TXT | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/docs/ANDROID-QEMUD.TXT b/docs/ANDROID-QEMUD.TXT index 1364553..7841399 100644 --- a/docs/ANDROID-QEMUD.TXT +++ b/docs/ANDROID-QEMUD.TXT @@ -249,3 +249,27 @@ but lacked a lot of flexibility: The current implementation moves any service-specific code to the emulator, only uses a single socket and allows concurrent clients for a all services. + + +IV. State snapshots: +-------------------- + +Support for snapshots relies on the symmetric qemud_*_save and qemud_*_load +functions which save the state of the various Qemud* structs defined in +android/hw-qemud.c. The high-level process is as follows. + +When a snapshot is made, the names and configurations of all services are +saved. Services can register a custom callback, which is invoked at this point +to allow saving of service-specific state. Next, clients are saved following +the same pattern. We save the channel id and the name of service they are +registered to, then invoke a client-specific callback. + +When a snapshot is restored, the first step is to check whether all services +that were present when the snapshot was made are available. There is currently +no functionality to start start missing services, so loading fails if a service +is not present. If all services are present, callbacks are used to restore +service-specific state. + +Next, all active clients are shut down. Information from the snapshot is used +to start new clients for the services and channels as they were when the +snapshot was made. This completes the restore process. |