요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
=====================================================
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.
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
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)
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).
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.
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.
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.
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을 호출합니다.
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를 해제합니다.
복원된 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로 복구할 수 있습니다.
크기 결정, 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 정리를 설명합니다.
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-159Utility는 보통 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를 확인해야 합니다.
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-188Suspend와 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로 취급되므로 종료할 필요는 없습니다.
같은 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-193Resume 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.
요약·해설
userland-swsusp.rst:1-193Snapshot character device의 ioctl 계약, image 전송·무결성 및 suspend/resume utility의 필수 순서를 설명합니다.