← Documents Documentation/power/userland-swsusp.rst GitHub 원문 ↗

Linux 6.18.37 · Power

Documentation for userland software suspend interface

Snapshot character device의 ioctl 계약, image 전송·무결성 및 suspend/resume utility의 필수 순서를 설명합니다.

Source pathDocumentation/power/userland-swsusp.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

userland-swsusp.rst:1-193

Snapshot character device의 ioctl 계약, image 전송·무결성 및 suspend/resume utility의 필수 순서를 설명합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 =====================================================
2 Documentation for userland software suspend interface
3 =====================================================
4
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
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.
17
18 The interface consists of a character device providing the open(),
19 release(), read(), and write() operations as well as several ioctl()
20 commands defined in include/linux/suspend_ioctls.h . The major and minor
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
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.
29
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
34 The ioctl() commands recognized by the device are:
35
36 SNAPSHOT_FREEZE
37 freeze user space processes (the current process is
38 not frozen); this is required for SNAPSHOT_CREATE_IMAGE
39 and SNAPSHOT_ATOMIC_RESTORE to succeed
40
41 SNAPSHOT_UNFREEZE
42 thaw user space processes frozen by SNAPSHOT_FREEZE
43
44 SNAPSHOT_CREATE_IMAGE
45 create a snapshot of the system memory; the
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
50 SNAPSHOT_CREATE_IMAGE ioctl() again); after the snapshot
51 has been created the read() operation can be used to transfer
52 it out of the kernel
53
54 SNAPSHOT_ATOMIC_RESTORE
55 restore the system memory state from the
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
61 SNAPSHOT_FREE
62 free memory allocated for the snapshot image
63
64 SNAPSHOT_PREF_IMAGE_SIZE
65 set the preferred maximum size of the image
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
70 SNAPSHOT_GET_IMAGE_SIZE
71 return the actual size of the hibernation image
72 (the last argument should be a pointer to a loff_t variable that
73 will contain the result if the call is successful)
74
75 SNAPSHOT_AVAIL_SWAP_SIZE
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)
79
80 SNAPSHOT_ALLOC_SWAP_PAGE
81 allocate a swap page from the resume partition
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
85 SNAPSHOT_FREE_SWAP_PAGES
86 free all swap pages allocated by
87 SNAPSHOT_ALLOC_SWAP_PAGE
88
89 SNAPSHOT_SET_SWAP_AREA
90 set the resume partition and the offset (in <PAGE_SIZE>
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
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
96 swap files (see Documentation/power/swsusp-and-swap-files.rst for
97 details).
98
99 SNAPSHOT_PLATFORM_SUPPORT
100 enable/disable the hibernation platform support,
101 depending on the argument value (enable, if the argument is nonzero)
102
103 SNAPSHOT_POWER_OFF
104 make the kernel transition the system to the hibernation
105 state (eg. ACPI S4) using the platform (eg. ACPI) driver
106
107 SNAPSHOT_S2RAM
108 suspend to RAM; using this call causes the kernel to
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
118 The device's read() operation can be used to transfer the snapshot image from
119 the kernel. It has the following limitations:
120
121 - you cannot read() more than one virtual memory page at a time
122 - read()s across page boundaries are impossible (ie. if you read() 1/2 of
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)
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
130 and all swap pages allocated with SNAPSHOT_ALLOC_SWAP_PAGE (if any).
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
137 snapshot image from/to the kernel will use a swap partition, called the resume
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
141 a file on a partition that is unmounted before SNAPSHOT_CREATE_IMAGE and
142 mounted afterwards.
143
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.
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,
161 preferably using mlockall(), before calling SNAPSHOT_FREEZE.
162
163 The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
164 in the memory location pointed to by the last argument of ioctl() and proceed
165 in accordance with it:
166
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):
169
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
173 suspending utility SHOULD destroy it, preferably by zapping
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
179 that were mounted before SNAPSHOT_CREATE_IMAGE has been
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).
183
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.
194

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Snapshot character device의 역할과 open mode

1-33

이 문서는 Rafael J. Wysocki가 2006년에 작성했습니다. `swsusp.txt` 앞부분의 모든 경고와 FAQ가 userland interface에도 그대로 적용되므로 먼저 읽어야 합니다.

Userland software suspend에는 kernel과 system memory snapshot을 주고받는 전용 utility가 필요합니다. 원문은 당시 `http://suspend.sourceforge.net`에서 제공한 구현을 자체 suspend/resume utility 개발의 참고 자료로 안내합니다.

Interface는 `open()`, `release()`, `read()`, `write()` operation과 `include/linux/suspend_ioctls.h`에 정의된 여러 `ioctl()`을 제공하는 character device입니다. Major/minor는 각각 10과 231이며 `/sys/class/misc/snapshot/dev`에서 읽을 수 있습니다.

Device를 read-only로 열면 suspend mode, write-only로 열면 resume mode입니다. Read와 write를 동시에 열 수 없고 어느 mode든 한 번에 한 process만 열 수 있습니다.

`open()` 자체에도 side effect가 있습니다. Data structure를 할당하고 suspend mode에서는 `PM_HIBERNATION_PREPARE`, resume mode에서는 `PM_RESTORE_PREPARE` notification chain을 호출합니다.

Snapshot device mode
Open 방식Mode후속 operation
ReadSuspendKernel snapshot을 read()로 가져옴
WriteResume저장 image를 write()로 올림
동시/중복 open금지한 번에 하나의 opener만 허용

Open 방향이 utility의 역할을 결정합니다.

=====================================================
Documentation for userland software suspend interface
=====================================================

        (C) 2006 Rafael J. Wysocki <rjw@sisk.pl>

First, the warnings at the beginning of swsusp.txt still apply.

Second, you should read the FAQ in swsusp.txt _now_ if you have not
done it already.

Now, to use the userland interface for software suspend you need special
utilities that will read/write the system memory snapshot from/to the
kernel.  Such utilities are available, for example, from
<http://suspend.sourceforge.net>.  You may want to have a look at them if you
are going to develop your own suspend/resume utilities.

The interface consists of a character device providing the open(),
release(), read(), and write() operations as well as several ioctl()
commands defined in include/linux/suspend_ioctls.h .  The major and minor
numbers of the device are, respectively, 10 and 231, and they can
be read from /sys/class/misc/snapshot/dev.

The device can be open either for reading or for writing.  If open for
reading, it is considered to be in the suspend mode.  Otherwise it is
assumed to be in the resume mode.  The device cannot be open for simultaneous
reading and writing.  It is also impossible to have the device open more than
once at a time.

Even opening the device has side effects. Data structures are
allocated, and PM_HIBERNATION_PREPARE / PM_RESTORE_PREPARE chains are
called.

Freeze, snapshot 생성과 atomic restore ioctl

34-63

`SNAPSHOT_FREEZE`는 현재 process를 제외한 userspace process를 freeze합니다. `SNAPSHOT_CREATE_IMAGE`와 `SNAPSHOT_ATOMIC_RESTORE`가 성공하려면 먼저 호출해야 합니다. `SNAPSHOT_UNFREEZE`는 이 process들을 다시 thaw합니다.

`SNAPSHOT_CREATE_IMAGE`는 system memory snapshot을 만듭니다. 마지막 인수는 `int`를 가리켜야 하며, snapshot을 방금 만든 경로에서는 1, image로 memory state를 복원한 뒤 같은 ioctl에서 다시 돌아온 경로에서는 0이 저장됩니다. Snapshot 생성 뒤에는 `read()`로 kernel 밖으로 전송할 수 있습니다.

`SNAPSHOT_ATOMIC_RESTORE`는 `write()`로 미리 올린 snapshot image에서 system memory state를 복원합니다. Kernel에 완전한 image가 없으면 실패합니다. `SNAPSHOT_FREE`는 snapshot image용 memory를 해제합니다.

Snapshot의 두 반환 경로
SNAPSHOT_FREEZESNAPSHOT_CREATE_IMAGEvalue=1: read and save imagepower off or rebootwrite image during resumeSNAPSHOT_ATOMIC_RESTOREvalue=0: close snapshot device

복원된 system은 과거의 SNAPSHOT_CREATE_IMAGE 호출을 마치는 위치에서 다시 실행됩니다.

The ioctl() commands recognized by the device are:

SNAPSHOT_FREEZE
        freeze user space processes (the current process is
        not frozen); this is required for SNAPSHOT_CREATE_IMAGE
        and SNAPSHOT_ATOMIC_RESTORE to succeed

SNAPSHOT_UNFREEZE
        thaw user space processes frozen by SNAPSHOT_FREEZE

SNAPSHOT_CREATE_IMAGE
        create a snapshot of the system memory; the
        last argument of ioctl() should be a pointer to an int variable,
        the value of which will indicate whether the call returned after
        creating the snapshot (1) or after restoring the system memory state
        from it (0) (after resume the system finds itself finishing the
        SNAPSHOT_CREATE_IMAGE ioctl() again); after the snapshot
        has been created the read() operation can be used to transfer
        it out of the kernel

SNAPSHOT_ATOMIC_RESTORE
        restore the system memory state from the
        uploaded snapshot image; before calling it you should transfer
        the system memory snapshot back to the kernel using the write()
        operation; this call will not succeed if the snapshot
        image is not available to the kernel

SNAPSHOT_FREE
        free memory allocated for the snapshot image

Image 크기, swap 할당과 platform ioctl

64-117

`SNAPSHOT_PREF_IMAGE_SIZE`는 선호하는 image 최대 크기를 설정합니다. Kernel은 이 값을 넘지 않도록 노력하지만 불가능하면 만들 수 있는 가장 작은 image를 생성합니다. `SNAPSHOT_GET_IMAGE_SIZE`는 실제 hibernation image 크기를 마지막 인수의 `loff_t`에 반환합니다.

`SNAPSHOT_AVAIL_SWAP_SIZE`는 사용 가능한 swap byte 수를 `loff_t`에 반환합니다. `SNAPSHOT_ALLOC_SWAP_PAGE`는 resume partition에서 swap page 하나를 할당하고 성공하면 page offset을 `loff_t`에 저장합니다. `SNAPSHOT_FREE_SWAP_PAGES`는 이 ioctl로 할당한 page를 모두 해제합니다.

`SNAPSHOT_SET_SWAP_AREA`는 resume device와 partition 시작점에서 swap header까지의 offset을 설정합니다. 마지막 인수는 `kernel/power/suspend_ioctls.h`의 `struct resume_swap_area`를 가리켜야 합니다. Offset 단위는 `<PAGE_SIZE>`이고 swap partition은 항상 0, swap file은 0이 아닙니다. 자세한 내용은 `Documentation/power/swsusp-and-swap-files.rst`를 참조합니다.

`SNAPSHOT_PLATFORM_SUPPORT`는 인수가 0이 아니면 hibernation platform support를 enable하고 0이면 disable합니다. `SNAPSHOT_POWER_OFF`는 ACPI 같은 platform driver를 사용해 system을 ACPI S4 같은 hibernation state로 전환합니다.

`SNAPSHOT_S2RAM`은 즉시 suspend-to-RAM으로 들어갑니다. 반드시 앞에 `SNAPSHOT_FREEZE`, wakeup 뒤에 `SNAPSHOT_UNFREEZE`를 호출해야 합니다. 이 ioctl은 먼저 disk image를 만든 뒤 RAM suspend에 들어가는 suspend-to-both를 구현합니다. Battery가 충분하면 RAM에서 빠르게 resume하고 그렇지 않으면 저장 image로 복구할 수 있습니다.

Snapshot storage와 platform ioctl
ioctl결과
SNAPSHOT_PREF_IMAGE_SIZE선호 image 최대 크기 설정
SNAPSHOT_GET_IMAGE_SIZE실제 image byte 수 반환
SNAPSHOT_AVAIL_SWAP_SIZE사용 가능 swap byte 수 반환
SNAPSHOT_ALLOC_SWAP_PAGEResume partition page 할당
SNAPSHOT_FREE_SWAP_PAGESUtility가 할당한 swap page 해제
SNAPSHOT_SET_SWAP_AREAResume device와 PAGE_SIZE 단위 offset 지정
SNAPSHOT_PLATFORM_SUPPORTPlatform hibernation 지원 enable/disable
SNAPSHOT_POWER_OFFPlatform driver로 hibernation state 진입
SNAPSHOT_S2RAMSuspend-to-both의 RAM suspend 단계

크기 결정, storage 예약, 종료 state 선택을 utility가 조정합니다.

SNAPSHOT_PREF_IMAGE_SIZE
        set the preferred maximum size of the image
        (the kernel will do its best to ensure the image size will not exceed
        this number, but if it turns out to be impossible, the kernel will
        create the smallest image possible)

SNAPSHOT_GET_IMAGE_SIZE
        return the actual size of the hibernation image
        (the last argument should be a pointer to a loff_t variable that
        will contain the result if the call is successful)

SNAPSHOT_AVAIL_SWAP_SIZE
        return the amount of available swap in bytes
        (the last argument should be a pointer to a loff_t variable that
        will contain the result if the call is successful)

SNAPSHOT_ALLOC_SWAP_PAGE
        allocate a swap page from the resume partition
        (the last argument should be a pointer to a loff_t variable that
        will contain the swap page offset if the call is successful)

SNAPSHOT_FREE_SWAP_PAGES
        free all swap pages allocated by
        SNAPSHOT_ALLOC_SWAP_PAGE

SNAPSHOT_SET_SWAP_AREA
        set the resume partition and the offset (in <PAGE_SIZE>
        units) from the beginning of the partition at which the swap header is
        located (the last ioctl() argument should point to a struct
        resume_swap_area, as defined in kernel/power/suspend_ioctls.h,
        containing the resume device specification and the offset); for swap
        partitions the offset is always 0, but it is different from zero for
        swap files (see Documentation/power/swsusp-and-swap-files.rst for
        details).

SNAPSHOT_PLATFORM_SUPPORT
        enable/disable the hibernation platform support,
        depending on the argument value (enable, if the argument is nonzero)

SNAPSHOT_POWER_OFF
        make the kernel transition the system to the hibernation
        state (eg. ACPI S4) using the platform (eg. ACPI) driver

SNAPSHOT_S2RAM
        suspend to RAM; using this call causes the kernel to
        immediately enter the suspend-to-RAM state, so this call must always
        be preceded by the SNAPSHOT_FREEZE call and it is also necessary
        to use the SNAPSHOT_UNFREEZE call after the system wakes up.  This call
        is needed to implement the suspend-to-both mechanism in which the
        suspend image is first created, as though the system had been suspended
        to disk, and then the system is suspended to RAM (this makes it possible
        to resume the system from RAM if there's enough battery power or restore
        its state on the basis of the saved suspend image otherwise)

Snapshot stream의 page 경계와 release 정리

118-135

`read()`는 kernel에서 snapshot image를 가져옵니다. 한 번에 virtual memory page 하나보다 많이 읽을 수 없고 page boundary를 가로지를 수 없습니다. 앞 호출에서 page 절반만 읽었다면 다음 호출도 남은 절반까지만 읽을 수 있습니다.

`write()`는 system memory snapshot을 kernel에 올리며 `read()`와 같은 page 크기·boundary 제약을 받습니다.

`release()`는 snapshot image용 memory와 `SNAPSHOT_ALLOC_SWAP_PAGE`로 할당한 모든 swap page를 해제합니다. 따라서 close 전에 `SNAPSHOT_FREE`나 `SNAPSHOT_FREE_SWAP_PAGES`를 따로 호출할 필요가 없습니다. Device close 때 아직 frozen인 userspace process도 thaw합니다. 원문의 `SNAPSHOT_UNFREEZE` 표현은 문맥상 freeze 상태의 process 정리를 설명합니다.

read/write 제약
Operation최대 길이Boundary
read()1 virtual page가로지를 수 없음
write()1 virtual page가로지를 수 없음
release()해당 없음Image memory, swap pages, frozen tasks 정리

Transfer unit은 virtual memory page boundary 안에 머물러야 합니다.

The device's read() operation can be used to transfer the snapshot image from
the kernel.  It has the following limitations:

- you cannot read() more than one virtual memory page at a time
- read()s across page boundaries are impossible (ie. if you read() 1/2 of
  a page in the previous call, you will only be able to read()
  **at most** 1/2 of the page in the next call)

The device's write() operation is used for uploading the system memory snapshot
into the kernel.  It has the same limitations as the read() operation.

The release() operation frees all memory allocated for the snapshot image
and all swap pages allocated with SNAPSHOT_ALLOC_SWAP_PAGE (if any).
Thus it is not necessary to use either SNAPSHOT_FREE or
SNAPSHOT_FREE_SWAP_PAGES before closing the device (in fact it will also
unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
still frozen when the device is being closed).

Storage 선택과 opaque image 무결성

136-159

Utility는 보통 resume partition 또는 swap file을 snapshot 저장 공간으로 사용합니다. Swap file을 쓰면 그 file이 놓인 partition이 resume partition입니다. 하지만 필수 조건은 아니며, 빈 suspend 전용 partition이나 `SNAPSHOT_CREATE_IMAGE` 전에 unmount했다가 뒤에 mount하는 filesystem의 file도 사용할 수 있습니다.

Utility는 snapshot image 내부 data 순서를 절대 추정하면 안 됩니다. Image 내용과 구조는 전적으로 kernel 소유이며 이후 kernel release에서 바뀔 수 있습니다.

Resume 때 image의 data, metadata, header를 읽었던 양·형태·순서 그대로 한 byte도 바꾸지 않고 kernel에 써야 합니다. 그렇지 않으면 복원된 system의 동작은 예측할 수 없습니다.

`SNAPSHOT_ATOMIC_RESTORE`는 image 구조와 header 정보가 일관적인지 검사하고 불일치하면 실패합니다. 그러나 완전한 보호는 아니므로 userland utility도 checksum 같은 추가 수단으로 image integrity를 확인해야 합니다.

Opaque image 보존
read exact kernel imagestore all data + metadata + headerverify utility checksumwrite exact amount/form/orderkernel validates header consistencyatomic restore

Utility는 image를 해석하지 않고 완전한 byte stream으로 취급합니다.

Currently it is assumed that the userland utilities reading/writing the
snapshot image from/to the kernel will use a swap partition, called the resume
partition, or a swap file as storage space (if a swap file is used, the resume
partition is the partition that holds this file).  However, this is not really
required, as they can use, for example, a special (blank) suspend partition or
a file on a partition that is unmounted before SNAPSHOT_CREATE_IMAGE and
mounted afterwards.

These utilities MUST NOT make any assumptions regarding the ordering of
data within the snapshot image.  The contents of the image are entirely owned
by the kernel and its structure may be changed in future kernel releases.

The snapshot image MUST be written to the kernel unaltered (ie. all of the image
data, metadata and header MUST be written in _exactly_ the same amount, form
and order in which they have been read).  Otherwise, the behavior of the
resumed system may be totally unpredictable.

While executing SNAPSHOT_ATOMIC_RESTORE the kernel checks if the
structure of the snapshot image is consistent with the information stored
in the image header.  If any inconsistencies are detected,
SNAPSHOT_ATOMIC_RESTORE will not succeed.  Still, this is not a fool-proof
mechanism and the userland utilities using the interface SHOULD use additional
means, such as checksums, to ensure the integrity of the snapshot image.

Suspend utility의 memory lock과 반환값 처리

160-188

Suspend와 resume utility는 `SNAPSHOT_FREEZE` 전에 자신을 memory에 lock해야 하며 가능하면 `mlockall()`을 사용합니다. Utility 자체가 page out되면 frozen userspace에 의존할 수 있기 때문입니다.

`SNAPSHOT_CREATE_IMAGE`가 마지막 인수 위치에 1을 저장했다면 snapshot이 방금 생성되어 저장할 준비가 된 상태입니다. 전체 suspend를 취소하는 경우가 아니면 snapshot device를 닫아서는 안 됩니다. 취소하면서 image를 이미 저장했다면 header를 지우는 방법 등으로 image를 파기하는 것이 좋습니다. 계속 진행한다면 image 저장 뒤 반드시 power off하거나 reboot해야 합니다.

Snapshot 생성 전에 mount돼 있던 filesystem에는 read를 포함한 어떤 operation도 하지 않는 것이 좋습니다. 당시 mount되지 않았던 filesystem은 새로 mount해 image 저장 등에 사용할 수 있습니다.

반환값이 0이면 snapshot image에서 system state가 방금 복원된 경로입니다. Suspend utility는 snapshot device를 닫아야 하며 이후에는 일반 userland process로 취급되므로 종료할 필요는 없습니다.

SNAPSHOT_CREATE_IMAGE 반환값
의미필수 조치
1Snapshot 생성 직후Device 유지, image 저장, 취소 아니면 power off/reboot
0Image 복원 직후Snapshot device close, 일반 process로 계속

같은 ioctl 호출 지점이 suspend와 resume의 분기점입니다.

The suspending and resuming utilities MUST lock themselves in memory,
preferably using mlockall(), before calling SNAPSHOT_FREEZE.

The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
in the memory location pointed to by the last argument of ioctl() and proceed
in accordance with it:

1.         If the value is 1 (ie. the system memory snapshot has just been
        created and the system is ready for saving it):

        (a)        The suspending utility MUST NOT close the snapshot device
                _unless_ the whole suspend procedure is to be cancelled, in
                which case, if the snapshot image has already been saved, the
                suspending utility SHOULD destroy it, preferably by zapping
                its header.  If the suspend is not to be cancelled, the
                system MUST be powered off or rebooted after the snapshot
                image has been saved.
        (b)        The suspending utility SHOULD NOT attempt to perform any
                file system operations (including reads) on the file systems
                that were mounted before SNAPSHOT_CREATE_IMAGE has been
                called.  However, it MAY mount a file system that was not
                mounted at that time and perform some operations on it (eg.
                use it for saving the image).

2.        If the value is 0 (ie. the system state has just been restored from
        the snapshot image), the suspending utility MUST close the snapshot
        device.  Afterwards it will be treated as a regular userland process,
        so it need not exit.

Resume utility의 filesystem 금지 규칙

189-193

Resume utility는 suspend 전에 mount돼 있었을 가능성이 있는 filesystem을 mount해서는 안 되며, 그런 filesystem과 관련된 operation도 수행해서는 안 됩니다. 세부 동작은 kernel source code를 최종 기준으로 확인해야 합니다.

The resuming utility SHOULD NOT attempt to mount any file systems that could
be mounted before suspend and SHOULD NOT attempt to perform any operations
involving such file systems.

For details, please refer to the source code.