最新カーネルリリース

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

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

devfs 全面戦争

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

※ devfs - devfs はディレクトリ /dev 以下を独立した特殊なファイルシステムとする事で動的なデバイス管理をしようとするものです。Richard Gooch 氏によって開発されています。

• デバイスがますますダイナミックになっていること。

  それらはユーザの気まぐれで付けたり外したりされ、その時々で違う場所に現われる可能性があります。 古い UNIX のデバイスモデルでは、そういった物は動きまわったりしないことが仮定されていました。このため /dev 中の静的なデバイスノードの組は (通常は) 変化しません。

  ※ デバイスノード - デバイスノードは通常 /dev 以下に置かれているファイル群で、メジャー／マイナー番号とキャラクター型／ブロック型のデバイスタイプを持っており、デバイス名とカーネル内のデバイスドライバとを対応付ける役目を持っています。デバイスノードをオープンしたり読み書きしたりすると、それは対応するデバイスドライバに渡されて処理されます。これにより UNIX はデバイスへのアクセスと普通のファイルへのアクセスとを同様のやり方で行う事を可能としています。デバイスファイル, 特殊ファイルとも呼ばれます。

• デバイスのメジャー／マイナー番号の空間が使い尽くされようとしていること。

  メジャー番号は、ご存じのように、デバイスドライバーに対応しています。マイナー番号はデバイス自身によって解釈され、多くの場合、なんらかの方法で物理的なデバイスに対応づけられます。 現在 Linux はメジャーとマイナー番号のそれぞれに、高々 8 ビットを使わせています。

  ※ すなわち最大 256 (= 2 の 8 乗) 種のデバイスと、各デバイス種毎に最大 256 個のデバイスを区別する事が可能です。

  多数の SCSI ディスクを使っているシステムでは、デバイス番号の空間に既に無理が来ています。 USB システムは数百もの独立したデバイスを持つことが考えられます (そしてそれは現実にありそうな事です)。 明らかに、デバイス番号はこの種の構成をサポートするために存在しているわけではありません。

• ディレクトリ /dev が、整理されてない混乱状態にあること。

  ほとんどのディストリビューションの /dev には、 システムが使用しなければならないかもしれないデバイスノードのすべてが 含められています。 その結果、しばしば 2000 以上のエントリーが存在します。その大半はシステムに実際には存在していないデバイスに対応しています。 将来、可能なデバイスの数は爆発的に増え、/dev のサイズは凄まじく大きくなることが予測できます。

  そのように巨大なデバイスディレクトリーは、いくつかの管理上の問題を呈します。 また、これをただうんざりするものだと考えるユーザは多くいます。 その方々は、自分のコンピュータに実際に存在しているデバイスのみを /dev の中に見たいのです。

Devfs に反対の方々は、それはこの問題に対する誤った解決策だと主張しています。 いろんな問題を、それぞれ個別に攻撃（解決）するのではなく、 一度に解決しようとしているのだということです。 defvfs がデバイスパーミッションの一貫性を保つ方法 (シャットダウン時に tar を走らせる) には、 一部の方々はうんざりさせられています。 また多くの方が、カーネル空間でのファイルシステムは不要だと見ています。 さらに、Linux の VFS レイヤーとインタフェースする方法を批判し、 将来的に問題を引き起こすだろうと指摘する方々もいらっしゃいます。

※ VFS (仮想ファイルシステム) - カーネル内の各種のファイルシステムをまとめて、抽象化している層。

個々の方々の devfs についての意見に関わらず、 現時点では、devsf は次期安定カーネルの 2.4 には（またもや） 入りそうにないようです。 すでにフィーチャーフリーズ期間中なのに、 devsf にはあまりに多くの反対があるからです。

ではこの問題はどう解決されるのでしょうか？ この議論が始まったのはしばらく前で、 USB デバイスの番号付けを扱う方法を見つける試みとしてでした。 USB が動作する実装とともに 2.4 がリリースされるためには、 この問題は解決されていなければなりません。 以下は論戦を読んだ結果と、風向きを読む一般的な感覚による憶測です：

• デバイス番号は 16 から 32 ビットに変更になる。おそらく 10 ビットがメジャー番号で、22 ビットがマイナー番号に。 （デバイスタイプを 32 ビットより大きくすると、NFS で問題を引き起こします。）

  ※ NFS - UNIX で標準的に使用されているネットワークファイルシステム。

  ユーザ空間の方では、この変更は比較的簡単なはずです --- しばらく前から glibc は 64 ビットのデバイスタイプを使っているので。

  ※ glibc - GNU C ライブラリのバージョン 2.0 以降の事を指します。現在ポピュラーな Linux ディストリビューションのほとんど (Slackware Linux / Plamo Linux を除く) で利用されています。

  しかし、それでもこれは大きな変更で、たぶん 2.4 には「入らない」でしょう。

• 動的なデバイス管理を行うためには、ある種のユーザ空間のデーモンプロセスが必要だという点においては合意があるようです。

  ※ デーモンプロセス - 一般ユーザの目に触れない所で動いていて, 必要に応じて各種の処理を行うプログラム。

  devfs はその種のデーモンを提供しますが、多くの方々は、それは devfs のカーネルコードがなくても可能だと考えています。 本当に必要なのは、システムのハードウェア構成が変わった時に、その情報をユーザプロセスが知ることができるメカニズムです。 そのプロセスはデバイスノードを操作することができて、システム管理者が設定するローカルなポリシー (デバイスのパーミッション、デバイス名、起動させなければならないプロセス、ロードが必要なモジュール等) のすべてを実現します。 この種の "devd" (H. Peter Anvin 氏の用語) プロセスは、この問題に対する比較的軽量で柔軟な解決策となるでしょう。

• 一つ以上のメジャー番号が、 USB デバイス一般に割り付けられる。

  マイナー番号は、USB イベントに応じて対応する実際のデバイスファイルを生成／削除するユーザ空間のデーモンプロセスによって、動的に処理されます。

(参考資料：devfs FAQ (英語))。 また、このさなかに Richard Gooch 氏が devfs v123 をリリースしました (英語)。

knfsd パッチに関する注意

※ カーネル NFS サーバ - バージョン 2.0 以前の Linux では NFS サーバは単なるユーザプロセスとして動作していました。2.2 カーネルではカーネル空間で動作する knfsd が提供されており、性能や他の UNIX との互換性が向上していますが、これを利用するには主流カーネルに H.J. Lu 氏の knfsd パッケージに含まれるパッチを適用する必要があります。

最近の TCP の弱点の解説

先週、TCP スタックのどこに弱点が潜んでいるのかや、 推測可能な IP 識別番号が弱点なのかどうか、等についてかなりの混乱がありました。

※ TCP スタック - カーネル内で TCP プロトコルを処理しているプログラムです。プロトコルの処理を行うプログラムは IP, TCP, 等の各プロトコルを処理する層が積み重なった構造になっている事から「スタック」と呼ばれます。まとめて「TCP/IP スタック」といった呼ばれ方もします。

※ IP 識別番号 - IP パケットを分割して送らなければならない時に、それを受信側で再構成出来るように、個々の IP パケットには一意な 16 ビットの識別番号が付けられています。識別番号の生成アルゴリズムは予測が困難である事が望ましいと言えますが、実際に使用されているのは (単に +1 していくという物を含めて) 様々な実装があります。

（※ ということですので、ChangeLog の翻訳からは該当記事を 発行前に削除してしまいました。 詳しくは、下記メモをご覧下さい。）

一方、 Andrey Savochkin 氏は、 予測可能な IP 識別番号は彼が考えていた程大きな問題ではないという結論に 達しました、、、

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

• Ulrich Windl 氏の PPSkit 0.8.0 (英語) です。

• Keith Owens 氏は modutils-2.3.5 (英語) を最後とする一連のバージョンの modutils パッケージをリリースしました。 その中でも特に、このリリースはデフォルトの設定ファイルを /etc/conf.modules から /etc/modules.conf に変更しました。しかし当面は (必要であれば) 古い conf.modules ファイルを読みます。

• Trond Myklebust 氏は NFSv3 クライアントの移植の 2.3.21 へのパッチをアナウンスしました (英語)。

関連 URL

LWN

カーネル（原文）

LinuxHQ

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

Kernel traffic

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