基本的に新しいもの順（新しいニュースが上） になっておりますので、 ご注意下さい。

• 1999年9月23日〜29日
• 1999年9月16日〜22日

早く帰って来て Linus

※ Linus は、フィーチャーフリーズ宣言 と同時に、しばらくオフを取ると宣言（日本語）していました。

なお、その後、 Linus がこのお休み中に実際に何をしていたのかが、 判明（日本語）しています。

安定版では、 2.2.13pre14 (英語) までが Alan によってリリースされています。 このパッチは、現時点でも印象的な数のパッチを含んでおり、 リリース版の候補と考えられています。 しかしながら、ここでカーネルハッカーの方々は、 最近突き止められた SMP IDE ハングのバグをどうやって修正するのかを、まず、 考え出さなければなりません。

一方、開発版では、パッチは 2.3.18ac10 (英語) まで出ています。

デバイスドライバはカーネルソースの一部であるべきか？

デバイスドライバ開発者のほとんどは、 自分達のコードが主流カーネルの一部として配布されるように努力するのですが、 その一方、ドライバは分離して保守され、配布されるべきだと考える方々もいます。 この観点からの主張は以下の通りです：

• すでに機器の種類は信じられないほど多く、 しかも日々増え続けています。 それらすべてのドライバをカーネルのソースツリーに含めるのは、 ソースを肥大化させ、巨大で保守できない代物にしてしまうことになります。

• 最近のハードウェアの世代交替の周期は、 カーネルの開発周期よりも短くなっています。 ドライバを別個に保守すれば、いつでもアップデートすることができます。 それに対して、カーネルの内部にあるドライバは 次の安定版のリリースを待たなければなりません。

• 既に Windows がそうであるように、 Linux 用のドライバフロッピーもハードウェアに付いてくるべきです。 ユーザは単にベンダーから提供されたフロッピーを突っ込むだけで、 カーネルの再構築のようなことを心配しなくても済むようになっているべきです。

• カーネル内のすべてのドライバは、Linus のパッチ処理の負荷を上げます。 「Linus」は無限の資源ではありません。

• ドライバがカーネルに付いてくれば、 単純にユーザの手に入ることになります。 ウェブに出かけて、ドライバのありかを突き止めて、 たぶん複数の変種の中から選び、 そしてカーネルにそれを組み込まなければならない、というのは、 大抵のユーザがやる気になることを越えてしまっています。

• 最新のドライバが新しいカーネルと共にやって来る場合の方が、 カーネルのアップデートはずっと簡単です。

• カーネルと一緒に居るドライバは、 カーネルの変更により良く追従するでしょう。 カーネルの変更によって何かが壊れたときには、 人々はすぐに気付きます。 さらに、 そもそもカーネルの一部であるドライバは、 カーネルの変更によって動かなくなることが少ない、 という見方もあります。 開発者は特定の機能がどこで使われているかを見付けようとし、 問題が起こるのを防ぐよう勤めるでしょう。 ドライバのソースがどこか別の所にあると、 このようなフィードバックはありません。

• カーネル内のデバイスドライバは、 カーネル開発者にとって重要な例題集となっています。 この開発活動を別の場所に移してしまうと、 「コード探索」活動がより困難になってしまうことでしょう。 カーネルツリー内のコードは、 一般により多くの目玉に出会う（日本語）ことになります。 そして、メンテナー以外の方々によって改良される可能性が高くなります。

• ベンダーからのフロッピーで提供されるドライバはすべて、 ただ一つのディストリビューションや単一のパッケージ形式のみ をサポートしがちです。 優れた標準が現れるまでは、 ドライバをカーネル内に持っておくことが、 それがすべてのディストリビューションで動作することを保証する 最良の方法です。

カーネル開発のプロジェクト管理システム

カーネル向けプロジェクト管理システムの仕様の第 2版 (英語) が出ています。ソースコード管理や、バグの追跡等が扱われています。 野心的な提案で、 実際に構築されることはないだろうとも思われる 基盤技術も多く挙げられています。 カーネルハッカーの方々は、 (※プロジェクト管理システムを強要されるなら) むしろハッキングを止めたいと思うでしょう。

最初の版では、 （その真価は別として） この役割を Aegis に担わせることが提案されていました。

※ Aegis - ソフトウェアの更新を管理するシステムです。地球規模で分散した開発をサポートしており、開発チームのメンバがそれぞれ独自に行なった変更を、一つに統合することを支援します。最新版は 3.19 であり、GPL に基づいて配付されています。

※ BitKeeper - BitMover 社のソース管理システムです。Aegis と同様に地球規模で分散した開発環境でのソース管理をサポートします。これは古くから UNIX で使われて来たソース管理システムである sccs をベースにしていますが、現代風にグラフィカルなインタフェースも備えています。ホームページ (英語) によると現在はβテスト中とのことですが、一般向けには公開されていません。

※ フレームウォー - インターネット上のニュースグループやメーリングリスト上で争われる論争の事です。しばしば冷静な論争というよりは罵り合いになってしまいます。

※ Merced - Intel 社の次期 CPU の開発名称です。Intel 社は Merced で動作する Linux を開発するために努力しています。

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

• 須藤清一氏により、 I・O DATA 社の高速RS-232C拡張ボード RSA-DVII/S 用の（カーネル2.2.13pre14中の シリアルドライバに対する）パッチ（日本語） が公開されています。

  これにより、本来のスピードを出せるようになるようです。

  「ボードを買ったはいいけど単なる拡張シリアルボードと してしか使えなくてくやしい思いをしている方、試してみ て下さい。」

  とのことです。なお、 IO DATA 社の製品説明（日本語） によると、RSA-DVII/S は、

  「MP 対応ターミナルアダプタによる同期 128Kbps 転送時に必 要とされるDTE速度 230.4Kbps に余裕をもって対応。RSA シ リーズを使用すれば最高のスループットを実現することが でき、ターミナルアダプタおよび高速モデムの性能を最大 限に発揮します。また最高 921.6Kbps まで対応しているの で、将来さらに高速な DTE 速度を要求する端末が現れた場 合でも安心して使用できる将来設計です。」

  とのことです。

• H.J. Lu 氏から Knfsd 1.5.1 (英語) がリリースされました。

  ※ knfsd は 2.2 からの新機能である、カーネルベースの NFS サーバ機能を提供するためのパッケージです。

  当分の間、2.2 で NFS サーバを正しく機能させるためには H.J. が提供するパッチを当てる必要があります。

  ※ このパッチは knfsd パッケージに含まれています。残念ながら knfsd-1.5.1 に含まれるパッチは、2.2.13pre シリーズ (とおそらくは 2.2.13 正式版) には一部うまく当たらないようです。これらのパッチは 2.2.14 で主流カーネルに統合されることが期待されています。

  H.J. は NFS の開発について議論するための新しいメーリングリストについてアナウンス (英語) しました。このためのホストは VA Linux Systems 社が提供しています。

  ※ H.J. Lu 氏は libc5 の作者としても知られており、Linux をハックするために VA Linux Systems 社に雇われています。

  近い将来、Linux が真にエンタープライズ級の NFS の実装を手に入れることを期待して、 VA 社はこの分野で（もっと）本気の貢献をしたいようです。

• Ingo Molnar 氏がsmp-2.3.18-H3 (英語) を公開しました。 このパッチは、x86 系 CPU における SMP と割り込み処理の実装をやり直すもので、Linus と御対面する前に徹底的に検査をされる必要があります。

• David Mentre 氏は、最初の版からしばらくぶりとなる、最新版の SMP FAQ/HOWTO (英語) を公開しました。

• Netfilter 0.1.9 (英語) が Paul Rusty Russel 氏によってリリースされました。 Netfilter は新しいファイアウォール/マスカレードのシステムです。

  ※ Netfilter は 2.3 カーネルから導入され、従来の ipfwadm や ipchains を置き換えるものです。

Linus は今週もお休み

開発版の方では、 2.3.18ac8 (英語) が出ています。 このパッチは、（巨大な）バグ修正の集まりになっています。 これは、現在フィーチャーフリーズが実行されていることを考えると、 適切なことです。 「超」安定した 2.4 のリリースに向けて、着実に前進が続いています。

安定版の方では、 2.2.13pre9 （英語） までパッチが出ています。

※ カーネルリリースの最新情報はこちら（日本語）をご確認下さい。

Mon Oct 4 18:25:36 JST 1999 現在、 2.2.13pre14 が最新です。

カーネルハッキング HOWTO

Linux カーネルに統合されるべきコードを書くための、 最初の入門書になることが目的とされています。 Rusty によると、

「私はひどく不適任なので、 このドキュメントを（本当は）書きたくはなかったんです。 どうか分かって下さい。でも、いつも、こういうドキュメントを 読みたいと思っていて、自分で書くしかなかったんです。 私は単純に、最も良い慣例を説明し、 カーネルハックを始めるのに必要となる、最も一般的なものの 80% をカバーする ことを目指しました。」

Ext3 サポートの日は近い --- ジャーナリング機能の実装も

Stephen Tweedie 氏の ext3 パッチの第1弾は、2 週間前から 同氏の FTP サイト (英語) で公開されています。 最初のリリースは 2.2.2 カーネルでのみ動作する他、 いくつか知られている障害があります。 新しいリリース (0.0.2) は、「すごくすぐ」 リリースされることが約束されており、 さらに 2.2.12 もサポートするはずです。

なぜジャーナリングが有用なのでしょうか？

一言で言えば「システムがクラッシュした後で fsck が終るのを 待たなくてもよくなるから」。 詳しく説明するには、若干の背景となる知識を必要とします。

ファイルシステムとは、ディスク上に構築された複雑なデータの構造物です。 単純に見える操作でも、 ディスク上の何ヶ所かへの変更を起こすことになり得ます。 例えば、 新しいデータをいくらか、ファイルの末尾に付け加えると、 明らかに、 新しいデータがディスクに書き込まれる必要があります。 また、新しいディスクブロックの割り当てが必要となるかもしれないので、 ファイルのブロックポインタや、 i ノード、空きブロックのリスト、 そしておそらくはディスククォータのデータベースの更新も必要になるかもしれません。

※ ディスクブロック - ファイルシステム中でデータを格納する領域は、ある固定サイズのブロック単位で管理されています。例えば ext2 ファイルシステムのデフォルトでは 1024 バイトのブロックサイズが使用されます。ファイルの末尾に新しいデータを付け加えた結果、現在使用中のブロックに収まりきれなくなった場合、新しいブロックの割当てが必要となります。

※ i ノード - UNIX ではファイルを管理するために i ノードと呼ばれるデータ構造を使用します。i ノードにはファイルの大きさや更新日付、そしてファイルの実体が書き込まれている場所へのポインタ (ブロックポインタ) 等、重要な情報が含まれていますが、ファイル名は含まれていません。ファイル名だけは別のデータ構造 (ディレクトリ) で管理されるのが UNIX のファイルシステムの特徴です。

※ 空きブロックのリスト - ファイルシステム中の使用されていないディスクブロックの一覧表です。

※ ディスククォータ - UNIX においてユーザ毎にディスクの使用量を制限する機構。

充分にデバッグされたファイルシステムでは、これらの動きはすべて、 ユーザのあずかり知らぬ所で行われます。 けれどもそのユーザが、電源コードの場所についてもその無関心さを発揮して、 システム全体をダウンさせる時には、問題は顕在化します。 もし、新しいディスクブロックが既に割り当てられていたのに、 ファイルのブロックポインタが更新されていなかったなら、 そのディスクブロックは永久に床に転がったままになってしまいます。 もし空きブロックのリストへの変更が書き込まれていなければ、 後になってディスクブロックが第二のファイルに誤って割り当てられてしまう可能性があります。 本質的に、 一つの操作に必要な「全ての」変更がディスクに書き込まれていない限り、 クラッシュの結果、矛盾する混乱が招かれます。

古典的 Unix のこの問題の解決法は、 fsck と呼ばれる、役に立つ可愛い :-) ユティリティです。 fsck の仕事は、 ファイルシステム全体を堀り返して何らかのデータ構造の矛盾を見つけ出し、 何とかしてそれらを全部修正してしまおうとすることです。 Linux の fsck はこれについて、かなり良い仕事をしますが、 (1) そういった恐ろしいメッセージが流れて行くのを見ているのは楽しくない。 (2) 非常に長い時間がかかる （巨大な RAID ボリュームを fsck したことがある方ならお分かりでしょう）。

※ ほとんどのシステムで、クラッシュ後にシステムを再起動すると自動的に全てのファイルシステムに対して fsck が実行されるようになっています。これはクラッシュ後の再起動には (実際にファイルシステムが壊れているかどうかにかかわらず) 長い時間がかかる事を意味しています。

ジャーナリングは、この必要性をなくすことができるのです。

ジャーナリングにおいては、 ディスクのある領域（「ジャーナルファイル」）が ファイルシステムが使用する部分とは別に確保されます。 ファイルシステムが変更される際、 行われるべき変更はすべてジャーナルファイルに記録され、 そしてディスクへ書き込まれて、 その後、すべての書き込みが完了していることを示すために、 特別な「コミットレコード」が記録されます。 一度すべての変更がジャーナルファイルに書き込まれてからのみ、 実際のファイルシステム構造への変更を開始します。

これで、もしユーザがフロッピーの取り出しボタンと電源スイッチを間違えても、 修復は簡単です。 コミットレコードと共にジャーナルファイル中に記録されたすべての変更は、 ファイルシステム構造自体の中にコピーされます。 それ以外 (※コミットレコードがない) はすべて単に捨てられます。 ファイルシステムの整合性は保護されるよう （最初から）保証されており、fsck は必要ありません。 システムはすぐに復旧することができます。

Stephen のジャーナリングパッチは、非常に賢い方法で作られています。

標準的な ext2 ファイルシステムの構造は何も変更されていません。 通常の状態では、ext3 ファイルシステムは ext2 ファイルシステムとして 何の問題もなくマウントすることができます。 ジャーナルファイルについても、 まったくファイルシステム中の単なる普通のファイルです。

このため、変換ユティリティは必要ありませんし、 ext3 が動かなかった時に ext2 に戻すための心配をする必要もありません。

これは優れた作品です。 いったん安定すれば、Linux への非常に喜ばれる機能追加となるでしょう。

統合された PCMCIA ドライバの状況

※ PCMCIA - ノートパソコン等の拡張スロットに装着して使用する、ノート用モデムやノート用 SCSI カード等の PC カードのことです。

また、(少なくとも当分の間は) 別立ての PCMCIA パッケージを使用する 必要があるだろうということも指摘しておいたほうが良いでしょう。 カーネル内の他の機能と同様に、 PCMCIA もユーザ空間で動作するデーモンの助けを必要とします。 このため、PCMCIA 自体がカーネルに含まれたとしても、 cardmgr (※カードマネージャ、PC カードの抜き差しを監視します) デーモンを含むパッケージは今後も不可欠です。

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

• DIPC 2.0 (英語) 。 分散プロセス間通信（Distributed InterProcess Communication） パッケージです。

  DIPC は、他のマシンとメモリ共用する機能等により、 クラスタにまつわる諸々のことを簡単にしてくれます。

  ※ DIPC は、古くから System V 系 UNIX で使われている IPC (プロセス間通信) を、別のマシンとの間で行うことを可能にするものです。

• 超最先端 SMP パッチ (英語) が Ingo Molnar 氏によってリリースされました。

  SMP と割り込み処理のコードを大幅に整理することを目的としています。 Ingo はこれのテストに協力して下さる方々を探しています。

• Kmsgdump （英語）。 Willy Tarreau 氏によってリリースされた便利なユティリティです。 カーネルクラッシュからの回復と、 メッセージバッファの内容をフロッピーにダンプするためのものです。

  問題点を突き止めようとする方は、ぜひご利用下さい。
  

  ※ このユティリティを使えば、カーネルパニック時にメッセージを手で書き移す必要がなくなります。

PCMCIA ドライバを主流カーネルに含めるべきか？

※PCMCIA がカーネルパッケージ内でサポートされるようになりました（日本語）ので、ChangeLog ではカットされていた LWN 1999年6月10日号掲載の記事をお伝え致します。

PCMCIA を標準カーネルに含めることの利点 （カーネルの変更により良く追従できる、 別々のパッケージをインストールしなくても良い） vs 別々にしておくことの利点 （すべてのバージョンのカーネルに新しいカードのサポートを追加できる、 Linux 以外の OS をサポートできる）についていくらかの議論が続きましたが、 その後しばらくしてから本当の問題が明らかになりました。 どうやら Linus は彼の ピカピカの Sony Vaio ノートに Linux をインストールしようとして、すごくやっかいな事になったようです。 Linus は、「自分」が Linux をインストールするのに苦労するなら、 少なくとも幾人かのユーザは少しひるんでしまうかもしれない、 と考えていて、これは彼には我慢ならないことでした。

いったん、本当の問題が掘り出されると、より具体的で技術的な議論が行われました。 David Hinds 氏は彼の考え方で、 この問題を まとめて (英語) います。 この解決策の核心は、 PCMCIA を部分的にカーネルに含めない、ということのようです。 そうではなく、 ブート時にシステムの BIOS によって既に初期化されセットアップ済みの デバイスを使うことができるように、 カーネルが PCMCIA について必要最低限のことを理解していれば、 問題の大部分はなくなるでしょう。 この線での解決策が、2.3 シリーズのどこかに入るようです。 (最初の一歩は Werner Almesberger 氏のこのメモ (英語) に見ることが出来ます。氏は既にこの機能のいくらかを実装しました。)

関連 URL

LWN

カーネル（原文） (9/23)

LWN

カーネル（原文） (9/30)

LinuxHQ

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

Kernel traffic

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