前回(P638まで)
- 仮想→下層
- MBRでは機種非依存ではなく、CPUに依存するので、機種依存 互換機では汎用
- PC/AT(x86のなかの規格のひとつ)内ではOSはMBRから呼ばれることを前提につくられている(OSを起動する前の段階なので、OSは関係ない)
ほかにもPC-98(NEC)とかの規格がある 機種非依存ではCPUにかかわらずうごく
ブートローダ
- MBRのなかにLILOが入るけど、GRUBはMBRの中に入りきらないので、MBRからGRUBを呼び出す
UEFIはBIOSとMBRを代替するブートの仕組み セキュアブートまわりが面倒なのでUEFIはまだ浸透しきれてない
BIOS
- MBR(ハードディスクの先頭の1セクタのことで、機械語プログラムとパーティションの情報が入っている)
F11は本当に機種依存
- mi machine independent
- md machine dependent
今回(P639から)
14.4.2 カーネルスレッドの初期化
カーネルの中にはブート時に準備し、カーネルが実行しているあいだじゅう必要ないくつかのプロセスが存在
- カーネルプロセスを実行するためのモジュール
カーネルの実行が始まると、すべての新しいプロセスは既存のプロセスをforkすることで作られる
- システムが最初に起動したときにはプロセスは1つも実行していない
- swapperはプロセスゼロから作られる
- 昔のUnixは0番プロセスはスケジューラでforkすらしない
- スケジュールのスワッパーとスケジューラの違いがよくわからん
- ゼロ番を作ってからforkが作られる
Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳)
達人出版会
発行日: 2013-04-25
対応フォーマット: EPUB, PDF, ZIP
達人出版会
発行日: 2013-04-25
対応フォーマット: EPUB, PDF, ZIP
swapperプロセスのためのデータ構造の初期化が終了するとinitプロセスを作成
initプロセスにシグナルを送って情報伝達
それぞれのCPUはidleプロセスを持っている
- swapperとinitプロセスが準備されるとidleプロセスを起動
- idleプロセスの数を数えたらCPUの数が分かるかも知れない
14.4.3 デバイスモジュールの初期化
デバイスモジュールを初期化するために使用する主要なコンポーネント
- デバイスを初期化するまえにmbufサブシステムの準備が必要
- ネットワークで使うやつが結構多いイメージ
- サブインタラクトやソフトインタラクトはネットワーク専門ではなさそう
デバイスファイルシステムを初期化
- そのあとif_init()実行(インターフェースの初期化自体は行わない)
- SI_SUB_DRIVERSとSI_SUB_CONFIGUREモジュールを使ってデバイスの初期化
実時間クロックに関連するものが準備を必要とする
- initclocks()を使う
NTPやデバイスポーリング、時刻カウンタなどのサービスを開始
Cブロックの初期集合を確保して、Cリストに追加
Cブロック Cリストデータ構造において、実際のデータを保持するバッファ
- Cリスト システムがシリアルライン入出力を実現するために用いる、リンクリスト形式のデータ構造
14.4.4 カーネルローダブルモジュール
- カーネルモジュールの中には、システムの実行中にロードし、使用を停止し、アンロードできるものがある
- 実行中にカーネルサービスのロードとアンロードが可能であること
- 組み込み型アプリケーション
カーネルモジュールを実行時にロードアンロードすることの問題
- セキュリティ的な問題がある
- 以前は実行時にカーネルを変更することが不可能であった→ルート権限を取得することが出来るユーザであれば、カーネルを修正することができる
- なので、商用環境の場合は実行時に任意のサービスをロードすることを許可せずに完全に構築されたカーネルを用いる
ローダブルカーネルモジュールの宣言など
- すべてのモジュールはMODULE_VERSIONマクロによってバージョン情報が対応されている
- ブート時と実行時のどちらでもロード可能にする
- モジュールのイベントハンドラを作成し、そのモジュールハンドラのシステムコールをマクロを使ってエクスポートすることだけを考えていればよい
14.4.5 プロセス間通信の開始
IPCインターフェイスの起動に関与するモジュール
IPCをサポートする過程でロードしなければならないモジュール
- System V セマフォ
- 共有メモリ
- メッセージキュー
- 擬似デバイス
- ネットワークに関数ローダブルモジュール(通信ドメインを実行時にアンロードすることを許可するためには、ソケット層とドメインモジュールを大幅に改造)
14.4.6 カーネルスレッドの起動
- カーネルを稼動状態にするために必要なスレッドはすべて含まれているのが下の図
scheduler()関数を実行して、戻ってこない。この関数は、システムのCPU上で、カーネルスレッドとユーザレベルプロセスを実行するためのスケジューリング処理を直ちに開始。
14.5 ユーザレベルの初期化
- initプロセス実行開始で、システムの大部分が運用を開始して機能するようになる
- FreeBSDのシステムコールインタフェースを用いて実行
14.5.1 /sbin/init
- ブートストラップ手続きの最終段階
- マルチユーザモードでは、initはまずファイル/etc/rc(run-command)の中のコマンドを解釈するためのシェルを起動する
- /etc/rcスクリプトが正常に実行を完了すると、initは/etc/ttysファイルの中で各端末デバイスごとに自分自身のコピーをfork
- 実行中のシステムの終了処理などを管理
14.5.2 システム起動スクリプト
- /etc/rcファイルの中身はほとんど空
- /etc/rc.dディレクトリ内の様々なシステム起動スクリプトを順番に実行
- /etc/rc.conf /etc/defautls/rc.conf
- /etc/rc.confの設定を優先
- rcスクリプトシステムの中心はrcorder(プログラム)
- シェルスクリプトの集合を入力→分析→順序付けた名前のリストを出力
- ファイルシステムの検査は以前は絶対不可欠だったが、ソフトアップデートなどで不要になってきている
- fsck ファイルシステムのマウント前にその検査と修復
- 修復されたら、mountシステムコールの亜種を実行して、カーネルにルートファイルシステうに関するすべてのデータ構造を再度読みなおすように指示する
- 亜種って何？
- ファイルシステムの検査が終わると、ファイルシステムをマウントして、ルートファイルしすてむは書き込み可能な状態にアップグレードして、スワッピングとページングに使用するデバイスを有効化
14.5.3 /usr/libexec/getty
- initは、システム上のハードウェア端末回線それぞれについて/usr/libexec/gettyプログラムを起動
- 端末回線をオープンして初期化
- 回線のために新しいセッションを作成して、その端末がセッションの制御端末となるように要求
- ブレークキーの入力で回線速度を変更できる時代があったのだろうか
- gettyは最終的にログイン名を読み込んで、ログイン手続きを完了させるために/usr/bin/loginプログラムを実行
14.5.4 /usr/bin/login
- loginプログラムはユーザをシステムにログインさせる
- /usr/libexec/gettyによって起動→ユーザの名前が渡される
- 起動されたloginはユーザにパスワードの入力を促す
- ユーザがネットワーク接続を介してシステムを入ろうとするときにも起動するが、gettyとinitは関与しない
14.6 システム運用
- システムの起動手続きに関連する話題
14.6.1 カーネルコンフィグレーション
- /usr/sbin/configプログラムによって解釈されるコンフィグレーションファイルに記述
- カーネルを構築するためにユーザはmakeコマンドを実行
- コンフィグレーションファイルはカーネルがサポートすべきハードウェアとソフトウェア要素を定義
- カーネルをインストールするときには一部のモジュールもインストールされる
14.6.2 システムの終了と自動ブート
- システムの停止や再起動を支持したり、システムをマルチユーザからシングルユーザのモードに移行したりするために、いくつかのユーティリティプログラムを用意
- システムの再起動のためにrebootシステムコールが用意されている
- これは特権手続き
- システムの再起動のためにrebootシステムコールが用意されている
- 修復不能な障害(パニック)を発見すると、自発的に自分を再起動する
- 終了手続きのどの段階でイベントハンドラのfunctionが実行されるか
- カーネルの終了関数はまずshutdown_pre_syncに登録されている関数のリストを順番に実行して、次にローカルディスク上のファイルシステムを終了する
14.6.3 システムデバッグ
- FreeBSDは障害をデバッグするためのいくつかの機能を有する
- 一番使われるのがクラッシュダンプ
- doadump() 現在のコンテキストを保存して物理メモリの内容を二次記憶に書き出す
- savecoreでクラッシュダンプをディスクから取り出す
- gdbを使ってクラッシュダンプを分析
14.6.4 カーネルとの間の情報のやりとり
- 4.3BSD以前のシステム
- カーネルの情報を必要とするユーティリティは/dev/kmem特殊デバイスをオープンするが問題がある
- システムの異常終了
- アプリケーションの実行が遅い
- 機密情報を取得できてしまう
- 1つのプロセスエントリを取得するのに/dev/kmemを何度もシークして読み出さないといけない
- で、これらの問題点を解決するためにsysctlシステムコールを導入した
- 常に正しいデータ構造を返し、修正
- 名前リストを読み込まないので速い
- 機密情報にアクセスできない
- 一貫したアクセスを保証
- 他にも、sysctlシステムコールには以下の利点がある
- jailシステムコールと完全に協調(今で言うところのDocker)
- データ構造更新前に設定しようとする値を確認できる
- 情報は必要に応じて計算できる(要求が来たらその場で計算できるようにしたら速い)
- 安全モード(8.2節参照)で実行中でもスーパーユーザがカーネルパラメータを変更することを許す
- カーネルの情報を必要とするユーティリティは/dev/kmem特殊デバイスをオープンするが問題がある
- sysctlシステムコールはカーネル名前空間を管理情報ベース(MIB)によって表現 階層的名前空間
- 新しい部分木の追加
- 任意のsysctl情報を無効
- 固有の名前付け規則を定義
- すべてのアーキテクチャに対して機種非依存の部分と機種依存の部分を分割できる
全体のおさらい
メモリ管理サービス(3.5)
www.slideshare.net
シグナルまわり(4.7)
- sigaction
- sigprocmask
- sigaltstack
- sigreturn
sigsuspend
シグナル発生
www.slideshare.net
メモリまわり
www.slideshare.net
ページフォルト率のチェック (AS/400) - BC メモリ管理 - SAP Library
ページャ
www.slideshare.net
キャッシュ
www.slideshare.net
移植性
www.slideshare.net
トランスレーション・ルックアサイド・バッファ - Wikipedia
書籍
- 作者: マーシャル・カークマキュージック,ジョージ・V.ネヴィル‐ニール,砂原秀樹,Marshall Kirk McKusick,George V. Neville‐Neil,歌代和正
- 出版社/メーカー: アスキー
- 発売日: 2005/10/18
- メディア: 単行本
- クリック: 122回
- この商品を含むブログ (57件) を見る
最終回なので
会そのものの振り返りは、別エントリで書きます。
