Linux 下的關(guān)機和重啟流程對于一般的桌面應(yīng)用和網(wǎng)絡(luò)服務(wù)器來說并不重要，但是在用戶自己定義的嵌入式系統(tǒng)內(nèi)核中就有一定的研究意義，通過了解 Linux 關(guān)機重啟的流程，我們對它可以修改和自定義，甚至以此為基礎(chǔ)開發(fā)出全新的功能來。

1. 概述

在 Linux 下的關(guān)機和重啟可能由兩種行為引發(fā)，一是通過用戶編程，一是系統(tǒng)自己產(chǎn)生的消息。用戶和系統(tǒng)進行交互的方式也有兩個，一個是系統(tǒng)調(diào)用：sys_reboot，另一個就是 apm 或則 acpi 的設(shè)備文件，通過對其操作也可以使系統(tǒng)關(guān)機或者重啟。

2. 通過系統(tǒng)調(diào)用 sys_reboot 的重啟

這個系統(tǒng)調(diào)用定義了一系列的 MAGIC_NUMBER，在調(diào)用的開始部分首先檢查 MAGIC_NUMBER 是否正確，只有正確才繼續(xù)向下運行。在重啟的時候轉(zhuǎn)向分支

case Linux _REBOOT_CMD_RESTART:

首先使用 notifier_call_chain 向其它部分發(fā)出重啟的消息，然后調(diào)用 machine_restart 函數(shù)完成重啟。

machine_restart 函數(shù)的開始部分有一段SMP相關(guān)的代碼，主要完成多 CPU 時由一個 CPU 完成重啟操作，其它 CPU 處于等待狀態(tài)。之后系統(tǒng)根據(jù)一個變量 reboot_thru_bios 的內(nèi)容判斷重啟方式，通過閱讀 reboot_setup 我們可以得知，這個參數(shù)的內(nèi)容是在系統(tǒng)啟動時指定的，決定了是否利用 bios，事實上是系統(tǒng)復(fù)位后的入口 (FFFF：0000) 地址的程序進行重啟。在不通過 bios 進行重啟的情況下，系統(tǒng)首先設(shè)定了重啟標志，然后向端口 0xfe 寫入數(shù)字 0x64,這種重啟的具體原理我還不大清楚，似乎是模擬了一次 reset 鍵的按下，希望大家和我討論。在通過 bios 重啟的情況下，系統(tǒng)同樣先設(shè)定了重啟模式，然后切換到了實模式，通過一條 ljmp $0xffff,$0x0 完成了重啟。

3. 通過系統(tǒng)調(diào)用 sys_reboot 進行關(guān)機

在系統(tǒng)調(diào)用的處理分支上，我們可以看到，首先同樣是檢查 MAGIC_NUMBER，然后在

case Linux _REBOOT_CMD_POWER_OFF:

的執(zhí)行流程里面，又是使用 notifier_call_chain 發(fā)出了關(guān)閉計算機電源的消息，緊接著執(zhí)行了 machine_power_off 函數(shù)。我們在 machine_power_off 函數(shù)中可以看到，如果 pm_power_off 這個函數(shù)指針不為空，那么系統(tǒng)就會通過調(diào)用這個函數(shù)進行關(guān)機。在 apm 已經(jīng)加載的情況下 (SMP 除外)，實際上 pm_power_off 函數(shù)實際上指向了 apm.c 中的 apm_power_off，在這個函數(shù)里系統(tǒng)通過 apm_info 結(jié)構(gòu)里的值，使用切換到實模式關(guān)機，或者使用 apm_bios_call_simple 函數(shù)調(diào)用保護模式下的 apm 接口關(guān)機兩種方法。

4. apm 驅(qū)動本身的關(guān)機過程

apm 使用其注冊的設(shè)備的 ioctl 接口完成 apm 的操作，在 apm.c的do_ioctl 函數(shù)中可以看見處理的分支。這里只有 suspend 和 standby 的代碼，所以我們不能通過 ioctl 這種方法使用 apm 關(guān)機。

當用戶按下 POWER 開關(guān)的時候，如果有 apm 模塊，那么關(guān)機流程是由 apm 來處理的。apm 驅(qū)動在初始化的時候啟動了一個 apm 內(nèi)核線程：apm_mainloop，系統(tǒng)會在這里檢測到 POWEROFF 按鍵消息并且將其命名為 APM_SYS_SUSPEND，以區(qū)別 apm -s 設(shè)置的 APM_USER_SUSPEND 模式。緊接著進入了 apm_event_handler 函數(shù)，又從 apm_event_handler 函數(shù)進入了 check_events 函數(shù)，處理函數(shù)對應(yīng)的 case 分支上。系統(tǒng)同樣使用了 suspend 函數(shù)進行關(guān)機，不過由于其它參數(shù)的原因，suspend 最后調(diào)用的是關(guān)機的流程。

5. 解決問題實例

1) 按 POWER 鍵時某些主板死機

經(jīng)查只有某些特定的驅(qū)動裝載之后才會出現(xiàn)這樣的情況，并且當使用關(guān)機系統(tǒng)調(diào)用 sys_reboot 的時候沒有這樣的問題。分析 apm 的處理流程，懷疑是在關(guān)機前驅(qū)動程序沒有正確處理 apm 發(fā)出的詢問消息造成的。由于部分驅(qū)動程序沒有源代碼，決定 hack 掉 apm.c 的關(guān)機部分，讓兩種方式的關(guān)機走同樣的流程。于是把 apm.c 的 check_events 函數(shù)中對 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;



定義了一個用戶態(tài)應(yīng)用程序 poweroff_helper_path，當 POWEROFF 鍵按下的時候系統(tǒng)運行這個 kernel_helper 程序。我們再寫一個通過 sys_reboot 系統(tǒng)調(diào)用關(guān)機的程序，放在指定的位置下。死機的問題就解決了。

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 */ };



系統(tǒng)就可以切換到實模式中，然后跳轉(zhuǎn)到 7000H:0 位置開始執(zhí)行。

6. ACPI 概述

在 2.4.20 內(nèi)核中 ACPI 模塊被注明為試驗和未完成，里面有一部分功能也許沒有實現(xiàn)。如果 APM 和 APCI 兩個模塊同時編譯進內(nèi)核，APM 在 ACPI 前被加載，APM 起作用使 ACPI 退出。對于系統(tǒng)電量、電源實踐一類的支持（主要是在筆記本上有用），靠的是 acpid 這個 daemon 程序。

沒有一個功能類似 apm 的應(yīng)用程序切換狀態(tài)，acpi 的程序僅僅完成了對 acpi 狀態(tài)的查詢。用戶實現(xiàn) S0-S4 的功能可以直接向 /proc/acpi/sleep 文件中寫入數(shù)字來實現(xiàn)。通過讀出 (cat) 其中的內(nèi)容可以知道系統(tǒng)到底支持那些模式。

acpi 模塊的源代碼主程序在 linux/drivers/acpi/driver.c 中，如果向 sleep 文件寫東西，就轉(zhuǎn)到了 linux/drivers/acpi/ospm/system/sm_osl.c 文件的 sm_osl_proc_write_sleep 函數(shù)中，這個函數(shù)后來調(diào)用了 sm_osl_suspend 函數(shù)。在這個函數(shù)里完成了各種功能，包括保護各種狀態(tài)。最后真正的 sleep 是通過對 acpi_enter_sleep_state 的調(diào)用完成的，這個函數(shù)在 Linux /drivers/acpi/hardware/hwsleep.c 文件中，這里寫了 acpi 的寄存器使系統(tǒng)進入 sleep 狀態(tài)。寫寄存器的指令在這個目錄下面的 hwregs.c 中。

7. 總結(jié)

本文對 acpi 的介紹非常簡略，實際上 ACPI 必定會成為將來 Linux 內(nèi)核中首選的電源管理方式。由于目前官方代碼中 ACPI 版本較低，所以沒有太詳細的論述，希望將來的內(nèi)核能有所改進。