最新開発版カーネル 2.3.18: PCMCIA と DRM のカーネルへの統合

※ 最新リリースは、 カーネル情報のページ（日本語）でご確認下さい。

• 長い月日の後、ついに PCMCIA のサポートが主流カーネルに統合されました。

  現時点では基本的な構造は出来ていますが、 実際のドライバ自体はほとんどありません。

  個々のドライバには、新たに統合されたしくみの下で動作させるために、若干調整が必要になります。 David Hinds 氏 (PCMCIA マスター) は、整合性があり今後も継続出来るやり方を策定するまで、まだ個々のドライバを慌てて 追加しないように（アーカテクチャの変更の可能性があるので個々のドライバを新しいアーカテクチャに対応させることはまだしないように）要請しています。

• DRM（Direct Rendering Manager）もカーネルに統合されました。

  DRM は XFree86 4.0 の一部になる予定の DRI（Direct Rendering Infrastructure） に必要とされるカーネルレベルでのサポートです。

  簡単に言うと、DRI は X サーバに三次元の描画の機能を追加できるようにするものです。 逆に X サーバは、ビデオハードウェアが持っている描画機能によるメリットを受けられます。 結果として、セキュリティ的に安全に低レベルのハードウェアアクセスを行えるようになり、かつ、非常に高速な 3D グラフィックスが得られます。

  ※ 現状の Linux の X サーバは ioperm() システムコールを使って直接ハードウェアにアクセスしています。このために X サーバは root 権限で動作する必要があり、セキュリティ上狙われやすい点になっています。

  DRM に関する詳細は DRM の設計資料 (英語) をご覧ください。 また、DRI 一般についてはこちらの資料（英語）で議論されています。

  ※ [ Update ] (1999/10/04)
  後日読者の方から、上記記事に関する訂正がありました。

  まず Michael Callahan 氏のご指摘（英語。「Subject: direct rendering explanation in 9/16 LWN」の記事） によると、

  「…簡単に言うと、DRI は X サーバに三次元の描画の機能を追加できるようにするものです。逆に X サーバは、ビデオハードウェアが持っている描画機能によるメリットを受けられます。…」

  という部分はむしろ「逆」だということです。 （機能的には勿論 3次元処理が強化されるのですが、実際には、 「追加」するというよりむしろ「省略」する、つまり、 3D データが X サーバを経由しないようにするということのようです。） 今の X サーバでは 3D のレンダリングを行う場合、 3D データは X 経由でアプリケーションから 3D ビデオカードへと渡されるため、 「間接レンダリング（indirect rendering）」と呼ばれており、 DRM ではアプリケーションからビデオカードへと（文字通り）直接渡される、 （※ 3D では大量のデータの流れがあるので、このようにして、 X サーバを経由しないで済むので処理が高速化される。） とのことです。

  また、Rodolphe Ortalo 氏によるまた別のご指摘によると、 DRI によって、 セキュリティ的な問題が完全に解決されるわけではないので、 「セキュリティ」を強調するのは間違った印象を与えかねない、 とのことです。

  具体的には、

  「…結果として、低レベルのハードウェアアクセスをセキュリティ的に安全に行えるようになり、かつ、非常に高速な 3D グラフィックスを得られます。…」

  という部分で、DRI（Direct Rendering Infrastructure）は 、 X サーバと同程度にしか安全ではなく、DRM の目的とするところは、 「超高速」であると指摘してくださっています。

  氏からの投稿 （英語。「Subject: A comment on DRM (LWN, Sep. 16)」の投稿） に詳しい議論がありますのでご覧下さい。

2.3 のフィーチャーフリーズが有効に

Linus は、彼が二週間の休暇を取り、その間に届いたメールは捨ててしまう事でフィーチャーフリーズの開始を確実なものにするとアナウンス (英語) しています。 このため、システムに新機能を受け入れるように どんなに説得力のあるメールを書いて彼に送っても、何にもなりません。

計画では、二ヵ月間のフィーチャーフリーズの後、 確実なコードフリーズに入り、リリースはまだ年末に予定されています。 おそらく私達は、今回は本当に、クリスマスに 靴下に詰め込まれたカーネルを手にすることができるかもしれません。

※ 前回の 2.2 リリースは、当初、クリスマスの頃に、と予定されていましたが、 実際にリリースされたのは、それから1カ月後でした。

Alan Cox 氏が ac シリーズを再開

「ac」シリーズはフィーチャーフリーズの制限範囲内のパッチのみを含む事を目的としています。このためあまりエキサイティングな新機能はないでしょう。

執筆時点で最新のパッチは 2.3.18ac5 (英語) です。

※ Tue Sep 21 23:51:24 JST 1999 現在、 2.3.18ac7（英語）が最新です。

安定版カーネル 2.2.12: 岩のように安定した 2.2.13 を目指して

※ 最新リリースは、 カーネル情報のページ（日本語）でご確認下さい。

Alan Cox 氏はこちらでも精力的です。 既に 2.2.13-pre パッチは version 8（英語） になっています。 Alan は「岩のように安定した」2.2.13 を作りたいとコメントしています。 ユーザコミュニティには、もちろん、より歓迎されるでしょう。

これが完成したら、 次の 2.2.14 は knfsd パッチを取り込むことができるようになります。 (この議論は先週 （英語。日本語） 取り上げました)。

マルチメディア・プラットフォームとしての期待が高まる Linux

今週、Paul Winkler 氏が Benno Senoner 氏の「短いレイテンシに関するミニ HOWTO」(low-latency mini-howto)（英語） が web に公開されている事を指摘して下さいました。

※「ミニ HOWTO」の場所がこちら（英語）に移動になったようです。(11/28 更新) [Thanks to 池田さん]

ここでのレイテンシとは、アプリケーションが何かを行うため CPU の獲得を待たなければならない時間を指しています。 マルチユーザのオペレーティングシステムは比較的レイテンシが長くなる傾向があり、 そのため、 1 ミリ秒 (またはそれ以下) の時間内でイベントに応答しなければならないようなアプリケーションを走らせるのは困難になります。

Benno は最近、彼の最新のテストにおけるいくつかの結果 (英語) を投稿しました。主に Ingo Molnar 氏との協力によって行われたものです。

彼の結果：いまや Linux において 1 ミリ秒未満の応答時間を得ることは可能で、 最も長いレイテンシ (500 ミリ秒) でさえも、 何が起きているかを突き止めることができれば修正できるはず、 ということのようです。

結論的に Linux は、 リアルタイム系のハックや他のトリックを使わなくても、 安定したマルチメディア向けのプラットホームへの途上にある、 と十分考えることができます。

その他のパッチとアップデート

• Zoltan Boszormenyi 氏による、Athlon と Cyrix のプロセッサで MTRR が適切に動くようにするパッチ (英語) です。

• Richard Gooch 氏の Devfs v121 (英語) です。 Richard からは Devfs 99.5 (英語) も出ており、こちらは最新の devfs を 2.2 カーネルへ移植したものです。

関連 URL

LWN

カーネル（原文）

LinuxHQ

他のカーネル関連リソース（英語）

Kernel traffic

他のカーネル関連リソース（英語）