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

Linuxのメインフレームへの移植がどのように行われたのか、いよいよその実装方法を解説しましょう（編集局）

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

　前回「メインフレーム温故知新」では、メインフレームの使われ方やハードウェアにおける特徴的な実装について、歴史的背景を踏まえながら解説しました。基幹業務システムとして44年間も絶えず改良を重ねてきたメインフレームは、信頼性と品質、そしてパフォーマンスについては究極のプラットフォームだといえるでしょう。

　今回は、そのメインフレームにLinuxをどのように移植したのかについて、1998〜1999年の移植当時の状況を振り返りながら、その実装方法を解説します。

メインフレームへの移植準備

　Linuxをサポートされていないハードウェア・アーキテクチャに移植するには、まずはCコンパイラであるgcc（GNU C compiler）を対応させる必要があります。周知のようにLinuxは、カーネルをはじめ、ほぼすべてのパッケージがgccを前提にしてコンパイルされているためです。

　また、実行形式のバイナリモジュールを生成するためには、binutils（binary utilities）に含まれているgas（GNU assembler）やld（GNU linker）も必要となります。これらがそろうと、Cソースコードをコンパイルしてオブジェクトコードを生成し、実行可能なバイナリを作るという開発環境が整うことになります。その環境にてLinuxカーネルとランタイムライブラリであるglibc（GNU C library）を移植することで、Linuxシステムのベースコンポーネントがそろいます。

　つまり、新しいアーキテクチャに対応するには、最初にgccとbinutilsを移植し、次にカーネルとglibcを移植するという順番になります。これらのアーキテクチャ依存の差分を開発することで、Linuxシステムを異なるアーキテクチャへ容易に移植することができるのです（図1）。

図1　Linuxシステムブロック図

　組み込み系システムを開発されている方はよくご存じだと思いますが、このアプローチはメインフレームに特有なものではなく、一般的なLinuxの移植方法です。Linuxから見ると、メインフレームというアーキテクチャが1つ追加されるにすぎません。

■クロス開発環境の準備

　移植作業において最初にやったことは、gccとbinutilsをメインフレーム・アーキテクチャに対応させ、PCのLinuxシステム上にクロス開発環境を構築することでした。クロス開発環境が完成すれば、Cソースコードをクロスコンパイルすることでメインフレーム用のバイナリが生成できるようになります。

　実はgccは、20年前からすでにメインフレームをサポートしており、「i370」というアーキテクチャ名で対応していました。移植を検討し始めた当初はi370を使用していたのですが、i370は最新のハードウェア命令には対応できていなかったため、IBMドイツの開発チームでは1999年に新しいアーキテクチャ名「s390」および2000年に「s390x」を定義し、これらがgccやkernelに追加されました。

　s390は31ビットアドレッシング、s390xは64ビットアドレッシングのメインフレーム・アーキテクチャを示します。

　gccとbinutilsの移植が終わり、クロス開発環境の準備ができたら、カーネルの移植となります。作業を始めた時点での最新カーネルであったkernel 2.2.3をベースに開発を開始しました。

意外に簡単？ カーネルのメインフレーム対応

　Linuxはすでに複数のアーキテクチャに対応しており、カーネルのみならず、OSを構成する主要コンポーネントはすべて、GNUの思想に基づくマルチ・プラットフォームに対応する構造となっています。また、ルールに基づいたコーディングスタイルや開発手法が確立していました。そのため、メインフレームへの対応は意外にも簡単でした。

　Linuxシステムの構造を図2に示します。カーネル構造の中で、ハードウェア・アーキテクチャ依存の部分とアーキテクチャ独立（非依存）の部分とが明確に分けられており、ソースツリー構造の中で分かりやすく管理されています。Linuxカーネルを新しいハードウェアに対応させるには、アーキテクチャ依存のソースコードを追加することで対応できる仕組みになっています。

図2　Linuxシステム構造ブロック図

　カーネルのソースコード全体から見ると、アーキテクチャ依存のコードサイズは非常に少なく、どのアーキテクチャでも数％程度です。最初に公開されたメインフレーム対応のkernel 2.2.14のソースコードを基に集計した結果を表1に示します。

Total S/390 Code S/390（％） Linuxカーネル 2200000 35000 1.5 gcc 1700000 9000 0.5 gdb 1500000 8000 0.5 glibc 1200000 5000 0.4 binutils 80000 6000 0.75 strace 41000 200 0.5

表1　Linuxソースコードに対するメインフレーム対応の修正行数と比率

　カーネルソースコード全体の220万行のうち、メインフレームに対応するために追加されたアーキテクチャ依存コードは3万5000行であり、たった1.5％の追加によってLinuxカーネルがメインフレームに対応できたことが分かります。主要コンポーネントであるbinutilsやglibcなどについても比較していますが、これも1％に満たないコード追加によりメインフレームに対応できています。この結果を見て、GNUを前提としたLinuxの移植性の高さを再認識しました。

1/3

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

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

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