Linuxシャットダウン再起動プロセス分析
4606 ワード
http://www.ibm.com/developerworks/cn/linux/embed/l-rb/index.html
概要: linuxの下のシャットダウンと再起動の流れは一般的なデスクトップアプリケーションとネットワークサーバにとって重要ではありませんが、ユーザーが自分で定義した組み込みシステムカーネルには一定の研究意義があり、Linuxのシャットダウン再起動の流れを理解することで、私たちはそれを修正し、自己定義することができ、それに基づいて新しい機能を発行することができます.
1.概要
linuxでのシャットダウンと再起動は、ユーザープログラミング、システム独自のメッセージの2つの動作によって開始される可能性があります.ユーザーとシステムが対話する方法も2つあります.1つはシステム呼び出しです.sys_reboot、もう一つはapmまたはacpiのデバイスファイルであり、それを操作することでシステムをシャットダウンまたは再起動することもできます.
トップに戻る
2.システムからsys_を呼び出すrebootの再起動
このシステム呼び出しは一連のMAGICを定義した.NUMBER、呼び出しの開始部分でまずMAGIC_をチェックNUMBERが正しく動作しているかどうかは、正しくない場合のみ下向きに動作します.再起動時にブランチに移行
まずnotifier_を使用call_chainは他の部分に再起動のメッセージを送信し、machine_を呼び出します.restart関数は再起動を完了します.
machine_restart関数の開始部分にはSMP関連のコードがあり、主にマルチCPUを完了すると1つのCPUで再起動操作が完了し、他のCPUは待機状態にある.その後、システムは変数reboot_に基づいてthru_biosの内容判断再起動方式、reboot_を読むことでsetupでは,このパラメータの内容がシステム起動時に指定されていることが分かり,biosを利用するか否かが決定され,事実上システムリセット後のエントリ(FFFF:0000)アドレスのプログラムが再起動される.biosで再起動しない場合、システムはまず再起動フラグを設定し、ポート0 xfeにデジタル0 x 64を書き込む.この再起動の具体的な原理はまだよく分からないが、resetキーの押下をシミュレートしたようだ.皆さんと私に議論してほしい.biosで再起動した場合、システムは同様に再起動モードを設定し、その後実モードに切り替え、ljmp$0 xffff、$0 x 0で再起動を完了した.
トップに戻る
3.システムからsys_を呼び出すrebootシャットダウン
システム呼び出しの処理ブランチでは、まず同じようにMAGIC_をチェックすることがわかります.NUMBER、そして
の実行プロセスでは、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インタフェースのシャットダウンの2つの方法を呼び出します.
トップに戻る
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のシャットダウン部分を外し、2つの方式のシャットダウンを同じ流れにすることにした.そこでapm.cのcheck_events関数でのAPM_SYS_SUSPENDセクションは次のコードに書き換えられます.
ユーザー・ステータス・アプリケーションの定義helper_Path、POWEROFFキーが押されたときにシステムがこのkernel_を実行しますhelperプログラム.sysを通してrebootシステムはシャットダウンしたプログラムを呼び出し、指定した位置に置く.ハングアップの問題は解決した.
2)クイックリターン実モード再起動
主にprocess.cの実モードを返すコードを参考にすることができます.例えばreal_mode_switchを次のコードに変更します.
システムは実モードに切り替えることができ、7000 H:0の位置にジャンプして実行を開始します.
トップに戻る
6.ACPIの概要
2.4.20カーネルではACPIモジュールが試験と未完成と明記されており、一部の機能が実現していない可能性がある.APMとAPCIの2つのモジュールが同時にカーネルにコンパイルされると、APMはACPIの前にロードされ、APMはACPIを終了させる役割を果たす.システムの電力量、電源の実践のようなサポート(主にノートパソコンで役に立つ)は、acpidというdaemonプログラムに頼っています.
apmのような機能を持つアプリケーションの切り替え状態はなく、acpiのプログラムはacpiの状態に対するクエリーを完了しただけです.ユーザがS 0−S 4を実現する機能は、/proc/acpi/sleepファイルに直接数字を書き込むことによって実現することができる.システムがそれらのモードをサポートしていることは、その中のコンテンツを読み出すことによって分かる.
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バージョンが低いため,詳細な論述はなく,将来のカーネルの変更を望んでいる.
概要: linuxの下のシャットダウンと再起動の流れは一般的なデスクトップアプリケーションとネットワークサーバにとって重要ではありませんが、ユーザーが自分で定義した組み込みシステムカーネルには一定の研究意義があり、Linuxのシャットダウン再起動の流れを理解することで、私たちはそれを修正し、自己定義することができ、それに基づいて新しい機能を発行することができます.
1.概要
linuxでのシャットダウンと再起動は、ユーザープログラミング、システム独自のメッセージの2つの動作によって開始される可能性があります.ユーザーとシステムが対話する方法も2つあります.1つはシステム呼び出しです.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を完了すると1つのCPUで再起動操作が完了し、他のCPUは待機状態にある.その後、システムは変数reboot_に基づいてthru_biosの内容判断再起動方式、reboot_を読むことでsetupでは,このパラメータの内容がシステム起動時に指定されていることが分かり,biosを利用するか否かが決定され,事実上システムリセット後のエントリ(FFFF:0000)アドレスのプログラムが再起動される.biosで再起動しない場合、システムはまず再起動フラグを設定し、ポート0 xfeにデジタル0 x 64を書き込む.この再起動の具体的な原理はまだよく分からないが、resetキーの押下をシミュレートしたようだ.皆さんと私に議論してほしい.biosで再起動した場合、システムは同様に再起動モードを設定し、その後実モードに切り替え、ljmp$0 xffff、$0 x 0で再起動を完了した.
トップに戻る
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インタフェースのシャットダウンの2つの方法を呼び出します.
トップに戻る
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のシャットダウン部分を外し、2つの方式のシャットダウンを同じ流れにすることにした.そこで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 = %d\
",
poweroff_helper_path, errno);
}
break;
ユーザー・ステータス・アプリケーションの定義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 */
};
システムは実モードに切り替えることができ、7000 H:0の位置にジャンプして実行を開始します.
トップに戻る
6.ACPIの概要
2.4.20カーネルではACPIモジュールが試験と未完成と明記されており、一部の機能が実現していない可能性がある.APMとAPCIの2つのモジュールが同時にカーネルにコンパイルされると、APMはACPIの前にロードされ、APMはACPIを終了させる役割を果たす.システムの電力量、電源の実践のようなサポート(主にノートパソコンで役に立つ)は、acpidというdaemonプログラムに頼っています.
apmのような機能を持つアプリケーションの切り替え状態はなく、acpiのプログラムはacpiの状態に対するクエリーを完了しただけです.ユーザがS 0−S 4を実現する機能は、/proc/acpi/sleepファイルに直接数字を書き込むことによって実現することができる.システムがそれらのモードをサポートしていることは、その中のコンテンツを読み出すことによって分かる.
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バージョンが低いため,詳細な論述はなく,将来のカーネルの変更を望んでいる.