第4回 メインフレームLinuxの実装(後編)



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

アイコン デバイスドライバの実装

 第3回でも解説したとおり、入出力装置をサポートするためのデバイスドライバは、メインフレームLinuxの移植当初はわずか6種類で、10年を経過した現在でも20種類程度しかありません。

 PCの世界では、さまざまなベンダからたくさんの種類のDVDやHDDやテープ装置、ネットワークインターフェイスカード(NIC)やディスプレイアダプタカードなどが販売され、それぞれにデバイスドライバが存在します。インターフェイスもATAPI、SCSI、USBなど複数あって、種類も豊富です。

 これに対してメインフレームは、入出力装置は基本的にチャネル接続しかありません。ディスクもテープもプリンタもネットワークも、チャネル経由でI/O処理します。チャネルは、物理的な仕様を決めているだけでなくプロトコルも規定しています。1種類のインターフェイスで1種類のプロトコルですから、非常にシンプルです。

 また、メインフレームに接続できるデバイス数は6万5536個までです。そのデバイスすべてにDMAとIRQがあって、CPUとは非同期で、それぞれのデバイスに対する処理を独立かつインテリジェントに実行します。また、それぞれのデバイスはサブチャネルとしてハードウェアの中で仮想化され、1〜8本のマルチパスでCPUとI/Oデバイスが接続されます。

 このマルチパス制御やエラー検知およびパスリカバリはすべてマイクロコードが行いますので、Linuxが考慮する必要はありません。さらに、動的構成変更として稼働中の付け外しが可能というハードウェア機能については、Linux HotPluggingにマップすることで対応しました。

 チャネルプロトコルには、デバイスの種類に依存しない共通部分が多いため、CIO(共通I/Oサポート)ルーチンを作って、ディスクやテープのようなチャネルデバイスごとのデバイスドライバからそれを呼び出す形式にして実装しました(図5)。前回の記事では、メインフレーム対応のための修正コード量が意外に少なかったことを解説しましたが、それには、デバイスの種類が少ないことや、I/Oがプロトコルを介してシンプルであることがかなり影響していると考えられます。

図5
図5 Common I/O Support Routinesによるデバイスドライバの共通化

■DASDドライバ

 メインフレーム用外部ディスク装置の主流はDASD(Direct Access Storage Device)です。既存の別OSで使用していたDASDをLinux用に再利用したり、LinuxのDASDをほかのメインフレームOSからアクセスできるようにすれば、相互運用性などの観点でメリットが大きいでしょう。そこでLinuxのDASDドライバは、z/OSなど既存OSとの互換性を持たせるように設計されています。

 別OSとの互換性については、テープドライバなど、ほかのデバイスドライバにおいても同様な方針で設計されました。

 Linux専用のデバイスドライバを設計すれば、ハードウェア性能とLinuxの特性に最適化したものができるでしょう。しかしメインフレームは、発現当初から互換性保証によって顧客の投資効率を優先してきました。ここでも設計方針は、パフォーマンスより互換性重視で決められました。

 DASD上のレイアウトは、図6のようなフォーマットになっています。DASDの先頭から、IPLレコード(ブート用)、VOL1(ボリュームラベル)、VTOC(Volume Table of Contents)、Partitionの順番になっています。このレイアウトはz/OSなど既存OSと互換であるため、Linuxのディスクでありながら、z/OSからコピーやバックアップを取得することなどが可能となっています。

図6
図6 DASDレイアウト(System z Compatible Disk Layout)

アイコン メインフレームLinuxが目指すところ

 メインフレームLinuxは、プロセッサ・アーキテクチャの性能を最大限に引き出すようなパフォーマンス重視の移植をしたのではなく、もともとメインフレームのアーキテクチャが持っている良さや、既存OSとの互換性を重視しており、バランスの取れたプラットフォームになるように努力してきました。勝手な実装をしてメインフレーム独自のLinuxにならないよう、移植性を最優先としながらも、Linuxが既存のメインフレーム文化とうまく融合していくことを志向しています。

[次回予告] 第5回 メインフレームLinuxの適用

メインフレームLinuxの適用エリアは、ほとんどがサーバ統合の領域です。Linuxによるサーバ統合は、メインフレームの旧来の考え方に回帰しているといえるかもしれません。もともとメインフレームは集中型システムですから、分散していたサーバを統合すれば、集中型に戻っていくわけです。そこで第5回では、メインフレームLinuxを用いたサーバ統合の考え方や方法論、そしてアプライアンス化と共有プールという新しい方向性について解説します。


前のページ
3/3
 

Index
あなたの知らないメインフレームLinuxの世界
 第4回 メインフレームLinuxの実装(後編)
  Page 1
メインフレームLinuxの仕様を知る
レジスタの使い方
メインフレームになかった命令
  Page 2
アーキテクチャ特有の実装の検討
Page 3
デバイスドライバの実装
メインフレームLinuxが目指すところ


Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Linux & OSS 記事ランキング

本日 月間