Commit | Line | Data |
---|---|---|
6e1819d6 RW |
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 | |
bf73bae6 RW |
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. | |
6e1819d6 RW |
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 kernel/power/power.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 | |
bf73bae6 RW |
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. | |
6e1819d6 RW |
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_ATOMIC_SNAPSHOT | |
31 | and SNAPSHOT_ATOMIC_RESTORE to succeed | |
32 | ||
33 | SNAPSHOT_UNFREEZE - thaw user space processes frozen by SNAPSHOT_FREEZE | |
34 | ||
35 | SNAPSHOT_ATOMIC_SNAPSHOT - 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_ATOMIC_SNAPSHOT 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_SET_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_AVAIL_SWAP - return the amount of available swap in bytes (the last | |
58 | argument should be a pointer to an unsigned int variable that will | |
59 | contain the result if the call is successful). | |
60 | ||
61 | SNAPSHOT_GET_SWAP_PAGE - allocate a swap page from the resume partition | |
62 | (the last argument should be a pointer to a loff_t variable that | |
63 | will contain the swap page offset if the call is successful) | |
64 | ||
65 | SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated with | |
66 | SNAPSHOT_GET_SWAP_PAGE | |
67 | ||
68 | SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument | |
69 | should specify the device's major and minor numbers in the old | |
70 | two-byte format, as returned by the stat() function in the .st_rdev | |
bf73bae6 RW |
71 | member of the stat structure) |
72 | ||
73 | SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE> | |
74 | units) from the beginning of the partition at which the swap header is | |
75 | located (the last ioctl() argument should point to a struct | |
76 | resume_swap_area, as defined in kernel/power/power.h, containing the | |
77 | resume device specification, as for the SNAPSHOT_SET_SWAP_FILE ioctl(), | |
78 | and the offset); for swap partitions the offset is always 0, but it is | |
79 | different to zero for swap files (please see | |
80 | Documentation/swsusp-and-swap-files.txt for details). | |
81 | The SNAPSHOT_SET_SWAP_AREA ioctl() is considered as a replacement for | |
82 | SNAPSHOT_SET_SWAP_FILE which is regarded as obsolete. It is | |
83 | recommended to always use this call, because the code to set the resume | |
84 | partition may be removed from future kernels | |
85 | ||
86 | SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to | |
87 | immediately enter the suspend-to-RAM state, so this call must always | |
88 | be preceded by the SNAPSHOT_FREEZE call and it is also necessary | |
89 | to use the SNAPSHOT_UNFREEZE call after the system wakes up. This call | |
90 | is needed to implement the suspend-to-both mechanism in which the | |
91 | suspend image is first created, as though the system had been suspended | |
92 | to disk, and then the system is suspended to RAM (this makes it possible | |
93 | to resume the system from RAM if there's enough battery power or restore | |
94 | its state on the basis of the saved suspend image otherwise) | |
95 | ||
a3d25c27 RW |
96 | SNAPSHOT_PMOPS - enable the usage of the hibernation_ops->prepare, |
97 | hibernate_ops->enter and hibernation_ops->finish methods (the in-kernel | |
98 | swsusp knows these as the "platform method") which are needed on many | |
99 | machines to (among others) speed up the resume by letting the BIOS skip | |
100 | some steps or to let the system recognise the correct state of the | |
101 | hardware after the resume (in particular on many machines this ensures | |
102 | that unplugged AC adapters get correctly detected and that kacpid does | |
103 | not run wild after the resume). The last ioctl() argument can take one | |
104 | of the three values, defined in kernel/power/power.h: | |
bf73bae6 | 105 | PMOPS_PREPARE - make the kernel carry out the |
a3d25c27 | 106 | hibernation_ops->prepare() operation |
bf73bae6 | 107 | PMOPS_ENTER - make the kernel power off the system by calling |
a3d25c27 | 108 | hibernation_ops->enter() |
bf73bae6 | 109 | PMOPS_FINISH - make the kernel carry out the |
a3d25c27 RW |
110 | hibernation_ops->finish() operation |
111 | Note that the actual constants are misnamed because they surface | |
112 | internal kernel implementation details that have changed. | |
6e1819d6 RW |
113 | |
114 | The device's read() operation can be used to transfer the snapshot image from | |
115 | the kernel. It has the following limitations: | |
116 | - you cannot read() more than one virtual memory page at a time | |
117 | - read()s accross page boundaries are impossible (ie. if ypu read() 1/2 of | |
118 | a page in the previous call, you will only be able to read() | |
119 | _at_ _most_ 1/2 of the page in the next call) | |
120 | ||
121 | The device's write() operation is used for uploading the system memory snapshot | |
122 | into the kernel. It has the same limitations as the read() operation. | |
123 | ||
124 | The release() operation frees all memory allocated for the snapshot image | |
125 | and all swap pages allocated with SNAPSHOT_GET_SWAP_PAGE (if any). | |
126 | Thus it is not necessary to use either SNAPSHOT_FREE or | |
127 | SNAPSHOT_FREE_SWAP_PAGES before closing the device (in fact it will also | |
128 | unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are | |
129 | still frozen when the device is being closed). | |
130 | ||
131 | Currently it is assumed that the userland utilities reading/writing the | |
bf73bae6 RW |
132 | snapshot image from/to the kernel will use a swap parition, called the resume |
133 | partition, or a swap file as storage space (if a swap file is used, the resume | |
134 | partition is the partition that holds this file). However, this is not really | |
135 | required, as they can use, for example, a special (blank) suspend partition or | |
136 | a file on a partition that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and | |
137 | mounted afterwards. | |
6e1819d6 RW |
138 | |
139 | These utilities SHOULD NOT make any assumptions regarding the ordering of | |
140 | data within the snapshot image, except for the image header that MAY be | |
141 | assumed to start with an swsusp_info structure, as specified in | |
142 | kernel/power/power.h. This structure MAY be used by the userland utilities | |
143 | to obtain some information about the snapshot image, such as the size | |
144 | of the snapshot image, including the metadata and the header itself, | |
145 | contained in the .size member of swsusp_info. | |
146 | ||
147 | The snapshot image MUST be written to the kernel unaltered (ie. all of the image | |
148 | data, metadata and header MUST be written in _exactly_ the same amount, form | |
149 | and order in which they have been read). Otherwise, the behavior of the | |
150 | resumed system may be totally unpredictable. | |
151 | ||
152 | While executing SNAPSHOT_ATOMIC_RESTORE the kernel checks if the | |
153 | structure of the snapshot image is consistent with the information stored | |
154 | in the image header. If any inconsistencies are detected, | |
155 | SNAPSHOT_ATOMIC_RESTORE will not succeed. Still, this is not a fool-proof | |
156 | mechanism and the userland utilities using the interface SHOULD use additional | |
157 | means, such as checksums, to ensure the integrity of the snapshot image. | |
158 | ||
159 | The suspending and resuming utilities MUST lock themselves in memory, | |
160 | preferrably using mlockall(), before calling SNAPSHOT_FREEZE. | |
161 | ||
162 | The suspending utility MUST check the value stored by SNAPSHOT_ATOMIC_SNAPSHOT | |
163 | in the memory location pointed to by the last argument of ioctl() and proceed | |
164 | in accordance with it: | |
165 | 1. If the value is 1 (ie. the system memory snapshot has just been | |
166 | created and the system is ready for saving it): | |
167 | (a) The suspending utility MUST NOT close the snapshot device | |
168 | _unless_ the whole suspend procedure is to be cancelled, in | |
169 | which case, if the snapshot image has already been saved, the | |
170 | suspending utility SHOULD destroy it, preferrably by zapping | |
171 | its header. If the suspend is not to be cancelled, the | |
172 | system MUST be powered off or rebooted after the snapshot | |
173 | image has been saved. | |
174 | (b) The suspending utility SHOULD NOT attempt to perform any | |
175 | file system operations (including reads) on the file systems | |
176 | that were mounted before SNAPSHOT_ATOMIC_SNAPSHOT has been | |
177 | called. However, it MAY mount a file system that was not | |
178 | mounted at that time and perform some operations on it (eg. | |
179 | use it for saving the image). | |
180 | 2. If the value is 0 (ie. the system state has just been restored from | |
181 | the snapshot image), the suspending utility MUST close the snapshot | |
182 | device. Afterwards it will be treated as a regular userland process, | |
183 | so it need not exit. | |
184 | ||
185 | The resuming utility SHOULD NOT attempt to mount any file systems that could | |
186 | be mounted before suspend and SHOULD NOT attempt to perform any operations | |
187 | involving such file systems. | |
188 | ||
189 | For details, please refer to the source code. |