基礎から覚える 最新OSのアーキテクチャー 第2回

ARM版Windows実現の鍵はマイクロカーネルにあり？

ハードウェア依存のプログラムをHALに任せる

　ある意味では、カーネルモードで動作しているプログラムは、カーネルの一部だと考えることもできる。しかし論理的な構造上、カーネルモードの中ではカーネル以外の呼び名を持つモジュールも動作している。

カーネルモードで動作するモジュール
モジュール	対応するファイル
HAL(Hardware Abstraction Layer)	HAL.DLL
デバイスドライバー	＊.sys
カーネル	Ntoskrnl.exe
Executive

　カーネルは下にHAL、上にExecutiveを持ち、横にデバイスドライバーを抱える構造になっている(図4)。

図4 Windows XP～Vistaのカーネル。Windows 95系との統合のために「Plug and Play Manager」が組み込まれ、「Configuration Manager」(レジストリ管理)も組み込まれた。なお、ここに「Power Manager」が入る場合もある。また「Cache Manager」は、古い説明図ではI/O Managerの中に含まれていた

　初期のWindows NTでは、Executiveはサービスとカーネル、HAL、デバイスドライバーの総称であった。一方現在のWindowsでExecutiveに相当する部分は、当時「Executive Service」と呼ばれていた(図5)。しかし現在では、Executiveはカーネルの上で動作する各種のマネージャー(デバイスやプロセス、プロセス間通信、メモリーなどを管理する部分)の集まりを指し、カーネルやHALとは別になっている。

図5 Windows NT 3.51以前(上)とそれ以降のWindows NT系でのExecutiveの違い

　カーネルとHALの関係を、割り込み処理を例に説明しよう。割り込み処理はカーネル内で処理されるが、CPUの割り込み状態を制御するには、割り込みコントローラーを操作しなければならない。そこで、割り込みコントローラーを操作するプログラムはHALに入れてしまう。そしてカーネル側は抽象的な操作で、HALを通じて割り込み原因を割り込みコントローラーから取得する。

　カーネルは割り込み原因を判定したら、原因ごとに登録されている割り込み処理を起動する。実際に割り込み処理を実行するプログラムは、カーネル外のExecutiveであったり、デバイスドライバーであったりする。

1年半でWindowsをARMアーキテクチャーへ移植

マイクロソフトはWindows 7リリース後の1年半ほどで、ARM版のWindowsのデモを披露して見せた。移植が容易なマイクロカーネルの利点が発揮されたのだろう

　本来の意味でのマイクロカーネルであれば、ファイルシステムなどを管理するExecutiveはユーザーモードで動作すべきだ。だがそうするとモードの切り替えが頻発するなどにより、処理の効率が悪くなってしまう。そのため、現在のWindowsでは論理的には分離されているものの、主要な機能はすべてカーネルモードで動作させて、ひとつのメモリー空間で動作するようになっている。

　では、Windowsのマイクロカーネルには意味がないのかというと、そんなことはない。例えば次期WindowsがARMプロセッサーに対応するように、異なるアーキテクチャーへの移植作業が(比較的)簡単になっている。カーネルモードで動作しているとはいえ、上位のExecutiveやデバイスドライバー、カーネルの大半の部分は、高級言語で記述されているし、アセンブラコードを必要とするようなハードウェアに依存した処理は、HAL側に閉じ込められている。そのため、異なるアーキテクチャーへの移植は比較的簡単に行なえる。

　マイクロソフトは2011年1月に、ARMプロセッサー上で次期Windowsを動作させるデモを披露した(関連記事)。見た目はほとんどWindows 7と同じもので、おそらくほぼ共通のソースコードから作られたものと見られる。Windows 7の完成は2009年7月のこと。いつの時点で次期WindowsのARM対応が決まったのかは不明だが、2011年1月までの約1年半の間に、まったく異なるアーキテクチャーへの移植が完了したわけだ。

　次期Windowsではx86とARMという、まったく異なる2種類のアーキテクチャーをサポートすることになるが、これが可能となるのもマイクロカーネルの利点によるものと言えよう。