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