挑战启动极速(6)--休眠恢复代替启动

本博客原创文章属本人lurker0ster所有，欢迎转载。
转载时需同意以下条件：
1. 必须保持版权信息，以及文章出处http://blog.csdn.net/lurker0ster/
2. 不准演绎，修改，必须完整转载全部内容。

===================分割线====================

启动的时间不仅仅只是内核启动的时间，还包含了Xorg和GNOME之类的桌面环境的启动时间。现在的内核启动虽然还有改进空间，但是桌面环境的耗时也是很客观的。所以有一种快速启动的思路在于利用休眠镜像来代替正常kernel启动机器。由于镜像已经是所有初始化结束后的产物，所以理论上这种方法可以节省初始化过程中费时的硬件检测过程。

linux的休眠特性是在2.6.12之后加入的版本

休眠流程：
1。用户请求休眠
2。用户进程停止调度
3。挂起阶段。停止访问外设，这样他们就不会影响到状态保存
4。状态保存。在中断禁止的情况保存所有用到的内存
5。恢复resume(). 唤醒一部分设备以便于保存镜像到交换分区
6。保存镜像
7。再次挂起设备。
8。断电

在可定制的硬件环境下，这样做是非常有效的，比如说一家日本公司已经实现了的ARM平台的1.5s左右的启动时间，但是对于一个发行版来说，这种优化很困难。原因就是硬件太复杂，有些驱动并没有考虑到这种需求的存在，导致在执行特定操作时进行休眠就会出现问题。

休眠的理想状态是用户程序并不知道此事件已经发生。

为了解决这个问题，linux提供了notifer 接口提供给驱动编写者，用于在适当的时候
得到系统的通知。Documentation/power/notifiers.txt就描述了这种接口。
比如
PM_HIBERNATION_PREPARE    系统即将休眠

在windows平台上，同样也有这样的问题。问题不那么严重的原因是windows的驱动模型很早就加入了电源管理的部分，驱动编写者必须按照手册规范编写对应的电源管理实现才能良好地支持休眠恢复，否则在驱动授权测试中就会失败。当然那些没有通过微软测试就发布的厂商驱动还是可能有潜在的问题。
linux有一套测试套件确保了一些问题可以在早期版本测试中发现并修正，但是实际中它还是依赖于用户发现问题然后提交bug的方式来发现深层次的问题。

除去上述问题，休眠还有一些限制：
1。休眠恢复前后不能有硬件变动
2。保存的镜像必须小于总内存的50%（因为要把代码恢复到原始位置）
3。如果不采用加密形式。用户进程中的敏感数据在swap上是明文保存。任何有swap 读权限的程序都可以访问。
4。用户程序如果在休眠前正在访问U盘，这部分数据不会保存下来。
5。用户态驱动程序比如文件系统驱动可能会在用户进程冻结阶段被错误的冻结。（这个问题可以通过notifier.txt来解决）

这种应用上的复杂性有一部分是由休眠这个目标本身所带来的。休眠的设想应用就是恢复之后的环境和使用之前是一致的，但是用户使用环境的复杂性带来了设计时需要考虑过多的情况。