第3回　メインフレームLinuxの実装（前編）

日本アイ・ビー・エム株式会社
システムズ＆テクノロジー・エバンジェリスト
北沢 強
2008/9/8

ソースコードの変更比率は？

　Linuxカーネルのメインフレームへの移植がどのくらいの規模なのかを見るために、カーネルソースコード中のほかのアーキテクチャ依存コードを、ソースコードの行数で比較したものが図3です。wcコマンドで簡単に数えたものなので必ずしも厳密なものではありません。また、公平を期するため、デバイスドライバの種類の多さで左右されないよう、ドライバの行数も除いています。

図3　アーキテクチャ依存コードのサイズ比較

　この図を見ますと、メインフレーム用のコードはほかのアーキテクチャ（ppc、alpha、SPARC、SPARC64）に比べて半分以下であることが分かります。

　Intel（i386）のコードが多いのは、周辺チップのサポートや電源制御などまで含まれているためですが、ppc、alpha、SPARC系のコードが多いのは、RISCプロセッサであることが主因であると考えられます。i386とs390はCISCプロセッサであるため高機能な命令が類似しており、s390はi386が持つ命令を包含していますが、RISCプロセッサは高機能な命令を複数の単純命令を組み合わせてエミュレーションすることとなり、カーネル内のアセンブラで書かれたエミュレーションコードが行数を多くしているようです。

　カーネルソースコード開発の中でも移植作業量が最も多かったのは、デバイスドライバの開発でした。カーネルソースツリー内でアーキテクチャ依存のソースコードの行数を数えて、その比率をグラフ化したのが図4です。デバイスドライバの開発が、実にカーネル全体の7割を占めていました。

図4　カーネルソースツリー内の行数（単位は×1000行）と比率

　当初は、入出力装置をサポートするデバイスドライバとして以下の6種類を開発しました。

• OSA Token-ring（トークンリング用NICカード）
• OSA Ethernet（イーサネット用NICカード）
• SCLP Console（HMCコンソール）
• 3215 Console（VM仮想コンソール）
• DASD（ディスク装置）
• VM minidisk（VMディスク装置）

　メインフレームは、特に入出力装置が特徴的であることを第2回の記事で説明しました。チャネルによってI/Oが抽象化され、プロトコルを介してインテリジェントに処理する仕組みであり、ハードウェア（特にマイクロコード）の中で多くの処理をしてくれることから、ソフトウェアでの負担が小さい、つまりデバイスドライバが単純になるという利点があります。

　また、メインフレームはPCなどに比べてデバイスの種類が少ないことも特徴です。I/O装置は基本的にチャネル経由でしか接続できませんので、I/Oプロトコルは1種類です。

　例えばディスクの場合ですと、上記のとおり、当初は2種類のディスク用ドライバがありましたが、現在ではメインフレームにユニークなディスク用ドライバは1種類しかありません。VM minidiskはDASDを仮想化したディスク装置であり、処理上は同じ扱いにできるため、1つに統合されました。

　また、メインフレームに接続できるDASD（ディスク装置）は、IBM以外に日立やEMCなど複数のベンダから製品が販売されていますが、仕様であるチャネルプロトコルが規定されているため、それに則していれば互換性を担保することができ、1種類しかないデバイスドライバで対応できるのです。デバイスの種類が少ないということは、移植においては作業量が少なく楽になるとともに、コード量が少ないのでバグが取れやすく、品質面でもメリットがありました。

稼働テストにはz/VMをフル活用

　クロス開発環境でコンパイルすると、メインフレーム上で動くオブジェクトコードが生成されますが、当然ながらこのバイナリはPC上では動きません。このバイナリをメインフレーム上に転送して、実機上で稼働を確認する必要があります（図5）。

図5　クロス開発環境

　ここで威力を発揮したのが「z/VM」です。z/VMはメインフレーム用の仮想化環境を提供するOSです。IBMドイツでは学生アルバイトを含めて十数名で移植作業をしていましたが、1台のメインフレームを複数人が使用する際、仮想化による分割あるいはリソース共有は、開発者がそれぞれ独立に並行して作業できるので便利でした。

　特に、仮想化環境はテスト環境として強力です。デバッグトレース機能によってバグや不具合を容易に特定できるためです。

　z/VMはCPU、メモリ、I/Oをすべて完全仮想化しているため、命令追跡（instruction trace）やI/O追跡（I/O trace）、メモリダンプなどが、システムが稼働したままリアルタイムに取得できます。デバッグ機能も充実しており、ブレークポイントを設定してメモリ書き換えをしたり、特定のアドレスレンジだけ命令追跡するなどの作業が簡単にできるのです。Linuxに手を加えずにハードウェアとしてデバッグトレースができることは、品質改善の上で大きな効果がありました。

　仮想化による問題判別時のメリットは、このような開発時のみならず、運用フェーズにおいてもあります。本番稼働しているLinuxシステムにおいて何かトラブルが出たとしたら、z/VM（仮想化環境）でハードウェアなどのエラーを検知したり記録したりできますし、障害状況のスナップショットとして、メモリダンプやI/Oステータスの保存などもz/VMで行います。Linuxの例外事象における脆弱（ぜいじゃく）性を、仮想化環境であるz/VMが補完してくれるのです。

クロス開発からネイティブ開発へ

　Linuxカーネルとglibcの移植が終わると、メインフレーム上でLinuxシステムとしてIPL（Initial Program Load）できるようになります。IPLとは、メインフレーム用語でブートすることを意味します。メインフレーム上でカーネルが動き、その上でgccやbinutilsなどmakeできる環境が整い、ftpやtelnetなどネットワーク経由でのアクセスが可能になったところで、その後の移植作業はメインフレーム上で実施しました。

　クロス環境の場合は、make後の稼働確認テストのためにいちいちファイルを転送したりする必要があり、面倒だからです。また、クロス環境に特有のバグの可能性も否定できず、その後の作業はネイティブ環境（＝メインフレーム上）で行いました。

2/3

Index あなたの知らないメインフレームLinuxの世界 　第3回　メインフレームLinuxの実装（前編）

Page 1 メインフレームへの移植準備 意外に簡単？ カーネルのメインフレーム対応 　 Page 2 ソースコードの変更比率は？ 稼働テストにはz/VMをフル活用 クロス開発からネイティブ開発へ   Page 3 パッケージ移植はほぼスムーズに ベンチマークテストの意外な結果 そして公開へ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）