▆ Hibernate（冬眠）和Sleep（睡眠）是Linux电源管理在用户角度的抽象，是用户可以看到的实实在在的东西。它们的共同点，是保存系统运行的上下文后挂起（suspend）系统，并在系统恢复后接着运行，就像什么事情都没有发生一样。它们的不同点，是上下文保存的位置、系统恢复的触发方式以及具体的实现机制。▆ Suspend有两个层次的含义。
一是Hibernate和Sleep功能在底层实现上的统称，都是指挂起（Suspend）系统，根据上下文的保存位置，可以分为Suspend to Disk（STD，即Hibernate，上下文保存在硬盘/磁盘中）和Suspend to RAM（STR，为Sleep的一种，上下文保存在RAM中）；
二是Sleep功能在代码级的实现，表现为“kernel/power/suspend.c”文件。▆ Standby，是Sleep功能的一个特例，可以翻译为“打盹”。正常的Sleep（STR），会在处理完上下文后，由arch-dependent代码将CPU置为低功耗状态（通常为Sleep）。而现实中，根据对功耗和睡眠唤醒时间的不同需求，CPU可能会提供多种低功耗状态，如除Sleep之外，会提供Standby状态，该状态下，CPU处于浅睡眠模式，有任何的风吹草动，
就会立即醒来。▆ Wakeup这是我们第一次正式的提出Wakeup的概念。我们多次提到恢复系统，其实在内核中称为Wakeup。表面上，wakeup很简单，无论是冬眠、睡眠还是打盹，总得有一个刺激让我们回到正常状态。但复杂的就是，什么样的刺激才能让我们醒来？动物界，温度回升可能是唯一可以让动物从冬眠状态醒来的刺激。而踢一脚、闹钟响等刺激，则可以让我们从睡眠状态唤醒。对于打盹来说，则任何的风吹草动，都可以唤醒。而在计算机界，冬眠（Hibernate）时，会关闭整个系统的供电，因此想醒来，唯有Power按钮可用。而睡眠时，为了缩短Wakeup时间，并不会关闭所有的供电，另外，为了较好的用户体验，通常会保留某些重要设备的供电（如键盘），那样这些设备就可以唤醒系统。这些刻意保留下来的、可以唤醒系统的设备，统称为唤醒源（Wakeup source）。而Wakeup source的选择，则是PM设计工作（特别是Sleep、Standby等功能）的重点。

   1: const char *const pm_states[PM_SUSPEND_MAX] = {   2:         [PM_SUSPEND_FREEZE]     = "freeze",   3:         [PM_SUSPEND_STANDBY]    = "standby",   4:         [PM_SUSPEND_MEM]        = "mem",   5: };

这些Power State的解释如下：

▆ freeze

这种Power State，并不涉及具体的Hardware或Driver，只是冻结所有的进程，包括用户空间进程及内核线程。和我们熟知的“冬眠”和“睡眠”相比，就称为“闭目养神”吧（可想而知，能节省的能量是有限的）。

【注：我们在之前的描述中，并没有特别描述该State，因为它在较早的内核中，只是Sleep、Hibernate等功能的一部分，只是在近期才独立出来。另外一个原因是，该state的省电效果不是很理想，所以其引用场景也是有限的。】

▆ standby，即第2章所描述的Standby状态。

▆ mem，即通常所讲的Sleep功能，也是第2章所描述的STR，Suspend to RAM。

▆ disk，即Hibernate功能，也是第2章所描述的STD，Suspend to Disk。

▆ 将电源管理过程按照先后顺序，划分为多个步骤，如core、platform、devices等。这些步骤称作PM Test Level。▆ 系统通过一个全局变量（pm_test_level），保存系统当前的PM Test Level。该变量的值可以通过”/sys/power/pm_test“文件获取及修改。▆ 在每一个电源管理步骤结束后，插入PM test代码，该代码以当前执行步骤为参数，会判断当前的PM Test Level和执行步骤是否一致，如果一致，则说明该步骤执行成功。出于Test考量，执行成功后，系统会打印Test信息，并在等待一段时间后，退出PM过程。▆ 开发人员可以通过修改全局的Test Level，有目的测试所关心的步骤是否执行成功。

 1: static const char * const pm_tests[__TEST_AFTER_LAST] = {   2:         [TEST_NONE] = "none",   3:         [TEST_CORE] = "core",   4:         [TEST_CPUS] = "processors",   5:         [TEST_PLATFORM] = "platform",   6:         [TEST_DEVICES] = "devices",   7:         [TEST_FREEZER] = "freezer",   8: };

▆ 系统处于sleep状态时，产生了Wakeup event。此时应该直接唤醒系统。这一点没有问题。▆ 系统在进入sleep的过程中，产生了Wakeup event。此时应该放弃进入sleep。这一点就不那么容易做到了。例如，当Wakeup event发生在“/sys/power/state”被写之后、内核执行freeze操作之前。此时用户空间程序依旧可以处理Wakeup event，或者只是部分处理。而内核却以为该Event已经被处理，因此并不会放弃此次sleep动作。这就会造成，Wakeup event发生后，用户空间程序已经后悔了，不想睡了，但最终还是睡下去了。直到下一个Wakeup event到来。

▆ wakeup_count是内核用来保存当前wakeup event发生的计数。▆  用户空间程序在写入state切换状态之前，应先读取wakeup_count并把获得的count写回给wakeup_count。▆ 内核会比对写回的count和当前的count是否一致，如果不一致，说明在读取/写回操作之间，产生了新的的wakeup event，内核就会返回错误。▆ 用户空间程序检测到写入错误之后，不能继续后的动作，需要处理响应的event并伺机再次读取/写回wakeup_count。▆ 如果内核比对一致，会记录write wakeup_count成功时的event快照，后面继续suspend动作时，会检查是否和快照相符，如果不符，会终止suspend。▆ 用户空间程序检测到写入正确后，可以继续对state的写入，以便发起一次状态切换。而此时是安全的。

 1: static const char * const hibernation_modes[] = {   2:         [HIBERNATION_PLATFORM]  = "platform",   3:         [HIBERNATION_SHUTDOWN]  = "shutdown",   4:         [HIBERNATION_REBOOT]    = "reboot",   5: #ifdef CONFIG_SUSPEND   6:         [HIBERNATION_SUSPEND]   = "suspend",   7: #endif   8: };

▆ platform，表示使用平台特有的机制，处理STD操作，如使用hibernation_ops等。

▆ shutdown，通过关闭系统实现STD，内核会调用kernel_power_off接口。

▆ reboot，通过重启系统实现STD，内核会调用kernel_restart接口。

【注：以上两个kernel_xxx接口的实现，可参考“Generic PM之Reboot过程”。】

▆ suspend，利用STR功能，实现STD。该类型下，STD和STR底层的处理逻辑类似。