11.6. 高度なトピックス

11.6.1. どのように動くのでしょう?

FreeBSD は、“実行クラスローダ (execution class loader) ” と呼ばれる抽象的な機構を持っています。これは execve(2) システムコールへの楔という形で実装されています。

FreeBSD は、シェルインタプリタやシェルスクリプトを実行するための #! ローダを持った単一のプログラムローダではなく、 ローダのリストを持っているのです。

歴史的には、Unix プラットフォーム上の唯一のローダーがマジックナンバー (一般的にはファイルの先頭の 4 ないし 8 バイトの部分) の検査を行ないシステムで実行できるバイナリかどうかを検査し、 もしそうならバイナリローダーを呼び出すというようになっていました。

もし、そのシステム用のバイナリでない場合には、 execve(2) システムコールの呼び出しは失敗の戻り値を返し、 シェルがシェルコマンドとして実行しようと試みていたわけです。

この仮定は“現在利用しているシェルがどのようなものであっても”変わりません。

後に sh(1) に変更が加えられ、先頭の 2 バイトを検査した結果 :\n であれば代わりに csh(1) を呼び出す、 というようになりました (この変更は SCO が最初に行なったと思われます)。

現在の FreeBSD は、プログラムローダリストを走査します。 その際、空白文字までの文字列をインタプリタとして認識する、 通常の #! ローダを用いるため、 該当するものが存在しなければ最終的に /bin/sh がロードされます。

Linux ABI をサポートするため、FreeBSD は ELF バイナリを示すマジックナンバを確認します。 (ただし、この段階では FreeBSD、Solaris、Linux、そしてその他の ELF イメージ形式を使っている OS を区別することはできません)。

ELF ローダは、特殊なマーク (brand) があるかどうか探します。 このマークとは、ELF イメージのコメントセクションのことです。 SVR4/Solaris の ELF バイナリには、このセクションは存在しません。

Linux バイナリを実行するためには、 ELF バイナリに brandelf(1) で説明されている Linux のマークが付けられていなければなりません。

# brandelf -t Linux file

上のようにすることで、指定されたファイルは Linux のマークが付けられ、 ELF ローダが認識できるようになります。

ELF ローダが Linux マークを確認すると、 ローダは proc 構造体内の ある一つのポインタを置き換えます。システムコールは全て、 このポインタ (伝統的な Unix システムではこれは構造体の配列 sysent[] で、システムコールが含まれています) を通してインデックスされます。 さらに、そのプロセスには Linux カーネルモジュールに必要な シグナルトランポリンコード (訳注: シグナルの伝播を実現するコード) 用の特殊なトラップベクタの設定や、 他の (細かな) 調整のための設定が行なわれます。

Linux システムコールベクタは、 さまざまなデータに加えて sysent[] エントリーのリストを含んでおり、それらのアドレスはカーネルモジュール内にあります。

Linux バイナリがシステムコールを発行する際、トラップコードは proc 構造体を用いてシステムコール関数ポインタを 解釈します。そして FreeBSD ではなく Linux 用のシステムコールエントリポイントを得るわけです。

さらに、Linux モードは状況に応じてファイルシステム本来のルートマウントポイントを置き換えてファイルの参照を行ないます。 これは、union オプションを指定してマウントされたファイルシステム (unionfs ではありません!)が行なっていることと同じです。 ファイルを検索する際にはまず /compat/linux/original-path ディレクトリを、それから見つけられなかったときにのみ、 /original-path を調べます。 こうすることで、他のバイナリを要求するバイナリの実行を可能にしています (したがって、Linux 用プログラムツールは Linux ABI サポート環境下で完全に動作するわけです)。 またこれは、もし対応する Linux バイナリが存在しない場合に Linux バイナリが FreeBSD バイナリをロードしたり、実行したりすることが可能であること、 その Linux バイナリに自分自身が Linux 上で実行されていないことを 気付かせないようにする目的で、uname(1) コマンドを /compat/linux ディレクトリに置くことができる、 ということを意味します。

要するに、Linux カーネルが FreeBSD カーネルの内部に存在しているわけです。 カーネルによって提供されるサービス全ての実装の基礎となるさまざまな関数は FreeBSD システムコールテーブルエントリと Linux システムコールテーブルエントリの両方で共通に利用されています。 これらにはファイルシステム処理、仮想メモリ処理、シグナル伝送、System V IPC などが含まれますが、 FreeBSD バイナリは FreeBSD グルー (訳注: glue; 二者の間を仲介するという意味) 関数群、 そして Linux バイナリは Linux グルー関数群を用いる、 という点だけが異なります (過去に存在したほとんどの OS は、 自分自身のためのグルー関数群しか備えていません。 前述したように、システムコールを発行する際、 各々のプロセスの proc 構造体内にある、 ローダによって動的に初期化されるポインタを参照してアドレスを得る代わりに、 静的でグローバルな sysent[] 構造体の配列に システムコール関数のアドレスが直接格納されているのです)。

さて、どちらを本来の FreeBSD ABI (訳注: Applications Binary Interface; 同じ CPU を利用したコンピュータ間でバイナリを共有するための規約のこと) と呼ぶべきなのでしょうか? 実は、どちらが本来のものであるかということを論ずることに意味はありません。 基本的に、FreeBSD グルー関数群はカーネルの中に静的にリンクされていて、 Linux グルー関数群は静的にリンクすることも、 カーネルモジュールを介して利用することもできるようになっている、 という違いがあるだけ (ただしこれは現時点においての話であり、 将来のリリースで変更される可能性がありますし、 おそらく実際に変更されるでしょう) です。

あ、「でもこれは本当にエミュレーションと呼べるのか」って? 答えは「いいえ」です。これは ABI の実装であり、 エミュレーションとは異なります。エミュレータが呼び出されているわけではありません (シミュレータでもないことをあらかじめ断っておきましょう)。

では、これがよく “Linux エミュレーション”と呼ばれるのは何故でしょうか? それはもちろん FreeBSD の売りにするためでもあるのですが、 実際には、次のような理由によります。 この機能が初めて実装された頃、 動作原理を説明する以外にこの機能を表現する言葉はありませんでした。 しかし、コードをコンパイルしたりモジュールをロードしない場合、 「FreeBSD 上で Linux バイナリを実行する」という表現は、 厳密に考えると適切ではありません。 そこで、その際にロードされているもの自身を表現する言葉 — すなわち “Linux エミュレータ”が必要だったのです。