Root/
1 | Documentation for userland software suspend interface |
2 | (C) 2006 Rafael J. Wysocki <rjw@sisk.pl> |
3 | |
4 | First, the warnings at the beginning of swsusp.txt still apply. |
5 | |
6 | Second, you should read the FAQ in swsusp.txt _now_ if you have not |
7 | done it already. |
8 | |
9 | Now, to use the userland interface for software suspend you need special |
10 | utilities that will read/write the system memory snapshot from/to the |
11 | kernel. Such utilities are available, for example, from |
12 | <http://suspend.sourceforge.net>. You may want to have a look at them if you |
13 | are going to develop your own suspend/resume utilities. |
14 | |
15 | The interface consists of a character device providing the open(), |
16 | release(), read(), and write() operations as well as several ioctl() |
17 | commands defined in include/linux/suspend_ioctls.h . The major and minor |
18 | numbers of the device are, respectively, 10 and 231, and they can |
19 | be read from /sys/class/misc/snapshot/dev. |
20 | |
21 | The device can be open either for reading or for writing. If open for |
22 | reading, it is considered to be in the suspend mode. Otherwise it is |
23 | assumed to be in the resume mode. The device cannot be open for simultaneous |
24 | reading and writing. It is also impossible to have the device open more than |
25 | once at a time. |
26 | |
27 | The ioctl() commands recognized by the device are: |
28 | |
29 | SNAPSHOT_FREEZE - freeze user space processes (the current process is |
30 | not frozen); this is required for SNAPSHOT_CREATE_IMAGE |
31 | and SNAPSHOT_ATOMIC_RESTORE to succeed |
32 | |
33 | SNAPSHOT_UNFREEZE - thaw user space processes frozen by SNAPSHOT_FREEZE |
34 | |
35 | SNAPSHOT_CREATE_IMAGE - create a snapshot of the system memory; the |
36 | last argument of ioctl() should be a pointer to an int variable, |
37 | the value of which will indicate whether the call returned after |
38 | creating the snapshot (1) or after restoring the system memory state |
39 | from it (0) (after resume the system finds itself finishing the |
40 | SNAPSHOT_CREATE_IMAGE ioctl() again); after the snapshot |
41 | has been created the read() operation can be used to transfer |
42 | it out of the kernel |
43 | |
44 | SNAPSHOT_ATOMIC_RESTORE - restore the system memory state from the |
45 | uploaded snapshot image; before calling it you should transfer |
46 | the system memory snapshot back to the kernel using the write() |
47 | operation; this call will not succeed if the snapshot |
48 | image is not available to the kernel |
49 | |
50 | SNAPSHOT_FREE - free memory allocated for the snapshot image |
51 | |
52 | SNAPSHOT_PREF_IMAGE_SIZE - set the preferred maximum size of the image |
53 | (the kernel will do its best to ensure the image size will not exceed |
54 | this number, but if it turns out to be impossible, the kernel will |
55 | create the smallest image possible) |
56 | |
57 | SNAPSHOT_GET_IMAGE_SIZE - return the actual size of the hibernation image |
58 | |
59 | SNAPSHOT_AVAIL_SWAP_SIZE - return the amount of available swap in bytes (the |
60 | last argument should be a pointer to an unsigned int variable that will |
61 | contain the result if the call is successful). |
62 | |
63 | SNAPSHOT_ALLOC_SWAP_PAGE - allocate a swap page from the resume partition |
64 | (the last argument should be a pointer to a loff_t variable that |
65 | will contain the swap page offset if the call is successful) |
66 | |
67 | SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated by |
68 | SNAPSHOT_ALLOC_SWAP_PAGE |
69 | |
70 | SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE> |
71 | units) from the beginning of the partition at which the swap header is |
72 | located (the last ioctl() argument should point to a struct |
73 | resume_swap_area, as defined in kernel/power/suspend_ioctls.h, |
74 | containing the resume device specification and the offset); for swap |
75 | partitions the offset is always 0, but it is different from zero for |
76 | swap files (see Documentation/swsusp-and-swap-files.txt for details). |
77 | |
78 | SNAPSHOT_PLATFORM_SUPPORT - enable/disable the hibernation platform support, |
79 | depending on the argument value (enable, if the argument is nonzero) |
80 | |
81 | SNAPSHOT_POWER_OFF - make the kernel transition the system to the hibernation |
82 | state (eg. ACPI S4) using the platform (eg. ACPI) driver |
83 | |
84 | SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to |
85 | immediately enter the suspend-to-RAM state, so this call must always |
86 | be preceded by the SNAPSHOT_FREEZE call and it is also necessary |
87 | to use the SNAPSHOT_UNFREEZE call after the system wakes up. This call |
88 | is needed to implement the suspend-to-both mechanism in which the |
89 | suspend image is first created, as though the system had been suspended |
90 | to disk, and then the system is suspended to RAM (this makes it possible |
91 | to resume the system from RAM if there's enough battery power or restore |
92 | its state on the basis of the saved suspend image otherwise) |
93 | |
94 | The device's read() operation can be used to transfer the snapshot image from |
95 | the kernel. It has the following limitations: |
96 | - you cannot read() more than one virtual memory page at a time |
97 | - read()s accross page boundaries are impossible (ie. if ypu read() 1/2 of |
98 | a page in the previous call, you will only be able to read() |
99 | _at_ _most_ 1/2 of the page in the next call) |
100 | |
101 | The device's write() operation is used for uploading the system memory snapshot |
102 | into the kernel. It has the same limitations as the read() operation. |
103 | |
104 | The release() operation frees all memory allocated for the snapshot image |
105 | and all swap pages allocated with SNAPSHOT_ALLOC_SWAP_PAGE (if any). |
106 | Thus it is not necessary to use either SNAPSHOT_FREE or |
107 | SNAPSHOT_FREE_SWAP_PAGES before closing the device (in fact it will also |
108 | unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are |
109 | still frozen when the device is being closed). |
110 | |
111 | Currently it is assumed that the userland utilities reading/writing the |
112 | snapshot image from/to the kernel will use a swap partition, called the resume |
113 | partition, or a swap file as storage space (if a swap file is used, the resume |
114 | partition is the partition that holds this file). However, this is not really |
115 | required, as they can use, for example, a special (blank) suspend partition or |
116 | a file on a partition that is unmounted before SNAPSHOT_CREATE_IMAGE and |
117 | mounted afterwards. |
118 | |
119 | These utilities MUST NOT make any assumptions regarding the ordering of |
120 | data within the snapshot image. The contents of the image are entirely owned |
121 | by the kernel and its structure may be changed in future kernel releases. |
122 | |
123 | The snapshot image MUST be written to the kernel unaltered (ie. all of the image |
124 | data, metadata and header MUST be written in _exactly_ the same amount, form |
125 | and order in which they have been read). Otherwise, the behavior of the |
126 | resumed system may be totally unpredictable. |
127 | |
128 | While executing SNAPSHOT_ATOMIC_RESTORE the kernel checks if the |
129 | structure of the snapshot image is consistent with the information stored |
130 | in the image header. If any inconsistencies are detected, |
131 | SNAPSHOT_ATOMIC_RESTORE will not succeed. Still, this is not a fool-proof |
132 | mechanism and the userland utilities using the interface SHOULD use additional |
133 | means, such as checksums, to ensure the integrity of the snapshot image. |
134 | |
135 | The suspending and resuming utilities MUST lock themselves in memory, |
136 | preferrably using mlockall(), before calling SNAPSHOT_FREEZE. |
137 | |
138 | The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE |
139 | in the memory location pointed to by the last argument of ioctl() and proceed |
140 | in accordance with it: |
141 | 1. If the value is 1 (ie. the system memory snapshot has just been |
142 | created and the system is ready for saving it): |
143 | (a) The suspending utility MUST NOT close the snapshot device |
144 | _unless_ the whole suspend procedure is to be cancelled, in |
145 | which case, if the snapshot image has already been saved, the |
146 | suspending utility SHOULD destroy it, preferrably by zapping |
147 | its header. If the suspend is not to be cancelled, the |
148 | system MUST be powered off or rebooted after the snapshot |
149 | image has been saved. |
150 | (b) The suspending utility SHOULD NOT attempt to perform any |
151 | file system operations (including reads) on the file systems |
152 | that were mounted before SNAPSHOT_CREATE_IMAGE has been |
153 | called. However, it MAY mount a file system that was not |
154 | mounted at that time and perform some operations on it (eg. |
155 | use it for saving the image). |
156 | 2. If the value is 0 (ie. the system state has just been restored from |
157 | the snapshot image), the suspending utility MUST close the snapshot |
158 | device. Afterwards it will be treated as a regular userland process, |
159 | so it need not exit. |
160 | |
161 | The resuming utility SHOULD NOT attempt to mount any file systems that could |
162 | be mounted before suspend and SHOULD NOT attempt to perform any operations |
163 | involving such file systems. |
164 | |
165 | For details, please refer to the source code. |
166 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9