DIY编程器网

标题: Linux 关机重启流程分析 [打印本页]

作者: admin 时间: 2014-10-11 02:43
标题: Linux 关机重启流程分析
Linux 下的关机和重启流程对于一般的桌面应用和网络服务器来说并不重要，但是在用户自己定义的嵌入式系统内核中就有一定的研究意义，通过了解 Linux 关机重启的流程，我们对它可以修改和自定义，甚至以此为基础开发出全新的功能来。

1. 概述

      在 Linux 下的关机和重启可能由两种行为引发，一是通过用户编程，一是系统自己产生的消息。用户和系统进行交互的方式也有两个，一个是系统调用：sys_reboot，另一个就是 apm 或则 acpi 的设备文件，通过对其操作也可以使系统关机或者重启。

2. 通过系统调用 sys_reboot 的重启

      这个系统调用定义了一系列的 MAGIC_NUMBER，在调用的开始部分首先检查 MAGIC_NUMBER 是否正确，只有正确才继续向下运行。在重启的时候转向分支

case Linux _REBOOT_CMD_RESTART:

首先使用 notifier_call_chain 向其它部分发出重启的消息，然后调用 machine_restart 函数完成重启。

machine_restart 函数的开始部分有一段SMP相关的代码，主要完成多 CPU 时由一个 CPU 完成重启操作，其它 CPU 处于等待状态。之后系统根据一个变量 reboot_thru_bios 的内容判断重启方式，通过阅读 reboot_setup 我们可以得知，这个参数的内容是在系统启动时指定的，决定了是否利用 bios，事实上是系统复位后的入口 (FFFF：0000) 地址的程序进行重启。在不通过 bios 进行重启的情况下，系统首先设定了重启标志，然后向端口 0xfe 写入数字 0x64,这种重启的具体原理我还不大清楚，似乎是模拟了一次 reset 键的按下，希望大家和我讨论。在通过 bios 重启的情况下，系统同样先设定了重启模式，然后切换到了实模式，通过一条 ljmp $0xffff,$0x0 完成了重启。

3. 通过系统调用 sys_reboot 进行关机

      在系统调用的处理分支上，我们可以看到，首先同样是检查 MAGIC_NUMBER，然后在

case Linux _REBOOT_CMD_POWER_OFF:

的执行流程里面，又是使用 notifier_call_chain 发出了关闭计算机电源的消息，紧接着执行了 machine_power_off 函数。我们在 machine_power_off 函数中可以看到，如果 pm_power_off 这个函数指针不为空，那么系统就会通过调用这个函数进行关机。在 apm 已经加载的情况下 (SMP 除外)，实际上 pm_power_off 函数实际上指向了 apm.c 中的 apm_power_off，在这个函数里系统通过 apm_info 结构里的值，使用切换到实模式关机，或者使用 apm_bios_call_simple 函数调用保护模式下的 apm 接口关机两种方法。

4. apm 驱动本身的关机过程

      apm 使用其注册的设备的 ioctl 接口完成 apm 的操作，在 apm.c的do_ioctl 函数中可以看见处理的分支。这里只有 suspend 和 standby 的代码，所以我们不能通过 ioctl 这种方法使用 apm 关机。

当用户按下 POWER 开关的时候，如果有 apm 模块，那么关机流程是由 apm 来处理的。apm 驱动在初始化的时候启动了一个 apm 内核线程：apm_mainloop，系统会在这里检测到 POWEROFF 按键消息并且将其命名为 APM_SYS_SUSPEND，以区别 apm -s 设置的 APM_USER_SUSPEND 模式。紧接着进入了 apm_event_handler 函数，又从 apm_event_handler 函数进入了 check_events 函数，处理函数对应的 case 分支上。系统同样使用了 suspend 函数进行关机，不过由于其它参数的原因，suspend 最后调用的是关机的流程。

5. 解决问题实例

1) 按 POWER 键时某些主板死机

经查只有某些特定的驱动装载之后才会出现这样的情况，并且当使用关机系统调用 sys_reboot 的时候没有这样的问题。分析 apm 的处理流程，怀疑是在关机前驱动程序没有正确处理 apm 发出的询问消息造成的。由于部分驱动程序没有源代码，决定 hack 掉 apm.c 的关机部分，让两种方式的关机走同样的流程。于是把 apm.c 的 check_events 函数中对 APM_SYS_SUSPEND 部分改写为如下代码：

ret = exec_usermodehelper(poweroff_helper_path, argv, envp); if (ret) { printk(KERN_ERR "apm.c: failed to exec %s , errno = %dn", poweroff_helper_path, errno); } break;

定义了一个用户态应用程序 poweroff_helper_path，当 POWEROFF 键按下的时候系统运行这个 kernel_helper 程序。我们再写一个通过 sys_reboot 系统调用关机的程序，放在指定的位置下。死机的问题就解决了。

2) 快速返回实模式重启

主要可以参考了 process.c 中的返回实模式的代码，比如我把 real_mode_switch 换成如下代码：

// For fast reboot support static unsigned char fast_reboot_switch [] = { 0x66, 0x0f, 0x20, 0xc0, /* movl %cr0,%eax */ 0x66, 0x25, 0x10, 0x11, 0x11, 0x11, /* andl $0x11111110,%eax */ 0x66, 0x0f, 0x22, 0xc0, /* movl %eax,%cr0 */ 0xea, 0x00, 0x00, 0x00, 0x70 /* ljmp $0x7000,$0x0000 */ };

系统就可以切换到实模式中，然后跳转到 7000H:0 位置开始执行。

6. ACPI 概述

      在 2.4.20 内核中 ACPI 模块被注明为试验和未完成，里面有一部分功能也许没有实现。如果 APM 和 APCI 两个模块同时编译进内核，APM 在 ACPI 前被加载，APM 起作用使 ACPI 退出。对于系统电量、电源实践一类的支持（主要是在笔记本上有用），靠的是 acpid 这个 daemon 程序。

没有一个功能类似 apm 的应用程序切换状态，acpi 的程序仅仅完成了对 acpi 状态的查询。用户实现 S0-S4 的功能可以直接向 /proc/acpi/sleep 文件中写入数字来实现。通过读出 (cat) 其中的内容可以知道系统到底支持那些模式。

acpi 模块的源代码主程序在 linux/drivers/acpi/driver.c 中，如果向 sleep 文件写东西，就转到了 linux/drivers/acpi/ospm/system/sm_osl.c 文件的 sm_osl_proc_write_sleep 函数中，这个函数后来调用了 sm_osl_suspend 函数。在这个函数里完成了各种功能，包括保护各种状态。最后真正的 sleep 是通过对 acpi_enter_sleep_state 的调用完成的，这个函数在 Linux /drivers/acpi/hardware/hwsleep.c 文件中，这里写了 acpi 的寄存器使系统进入 sleep 状态。写寄存器的指令在这个目录下面的 hwregs.c 中。

7. 总结

      本文对 acpi 的介绍非常简略，实际上 ACPI 必定会成为将来 Linux 内核中首选的电源管理方式。由于目前官方代码中 ACPI 版本较低，所以没有太详细的论述，希望将来的内核能有所改进。

欢迎光临 DIY编程器网 (http://diybcq.com./)