玩式草子─ソフトウェアとたわむれる日々

第87回 Linuxの成長過程をふりかえる[その5]

この記事を読むのに必要な時間:およそ 4 分

linux-2.3シリーズの新機能

さてそれではlinux-2.3シリーズではどのような新機能が追加されたのか,ソースコードをざっと眺めて目についたものを紹介してみましょう。

カーネルレベルでのPCカード対応

最近ではUSBやSDメモリカードに取って替わられほとんど見られなくなったものの,PCカードはノートPCの機能拡張用に広く使われていた周辺機器です。

当時は「PCMCIAカード」と呼ばれ,ソースコード中のディレクトリ名もpcmciaになっているものの,⁠PCカード」が公式な名称になったそうなのでそれに従うことにします。

PCカードは電話回線に接続するためのシリアル通信(モデム)やネットワーク,外付けHDDとのインターフェイスなどに利用されました。

図4 さまざまなPCカード

図4 さまざまなPCカード

実のところ,PCカードはlinux-1.xの時代からカーネル外部のサービスとして利用可能でした。当時のLinuxではPCカードのサポートはpcmcia-csパッケージとして提供され,このパッケージに含まれるcardmgrと呼ばれるデーモンがPCカードの抜き差しを監視し,必要なドライバモジュールをカーネルに組み込んだり取り外したりしていました。

当時,ノートPCの普及率が高かった日本ではPCカードへのニーズも高く,日本のユーザが開発したさまざまなPCカード用のドライバがpcmcia-csパッケージに取り込まれていったことを思い出します。

linux-2.3のシリーズでは,カーネル自身が周辺機器の活線挿抜に対応するようになり,それに伴なってPCカードもカーネルレベルで対応することになりました。その結果,linux-2.3.33ではdrivers/pcmcia/というディレクトリが用意され,pcmcia-csが提供していた機能の多くがカーネル内部に取り込まれることになりました。

devfs

カーネル自身が周辺機器の活線挿抜に対応するようになって深刻になったのがデバイスファイルの管理問題です。

Linuxがお手本にしたUNIXの設計では,ユーザ領域とシステム領域を厳密に区別するため,ユーザ領域のソフトウェア(アプリケーション)が周辺機器を利用する際はデバイスファイルという特殊なファイルを経由することになっています。このデバイスファイルは使いたい周辺機器それぞれに必要で,HDDなどの場合はパーティションごとに1つのデバイスファイルが必要になります。

それぞれのコンピュータ会社が閉じた世界を作っていたUNIXワークステーションの時代では,利用できる周辺機器も限られていたため,使うであろうデバイスファイルをあらかじめ全て用意しておくこともそれほど難しいことではありませんでした。

一方,膨大な種類の周辺機器が存在するPC環境で開発されたLinuxでは利用可能な周辺機器の種類も豊富で,それに応じて多種多様なデバイスファイルが必要になります。加えて活線挿抜で動作中に周辺機器が増えたり減ったりするとなると,それらをどうデバイスファイルと結びつけるのかという問題が生じてきます。

そのために考案されたのが,周辺機器のことを一番よく知っているカーネル自身に必要なデバイスファイルを動的に作らせるdevfsという仕組みです。

従来の方式ではデバイスファイルはルートファイルシステム上に用意したdevディレクトリ以下に,周辺機器を表わすメジャー番号,マイナー番号を指定して,mknodコマンドであらかじめ作っておく必要がありました。

それに対しdevfsでは,認識している周辺機器の情報を元に,専用のファイルシステム上にカーネル自身が必要なデバイスファイルを作成するように設計されています。devfsのコードはlinux-2.3.51でfs/devfs/以下に収められました。

実のところdevfsの機能はそれほど広く使われず,次の安定版であるlinux-2.4シリーズでも長く「実験的(experimental⁠⁠」のラベルが付いたままでした。その理由のひとつは,devfsが提供するデバイスファイル名が/dev/scsi/host0/bus0/target1/lun0/part6のようなスタイルで,伝統的な/dev/sda6といったスタイルとは大きく異なっていたことです。これらをシンボリックリンクで結びつけることも不可能ではないものの,そのような命名規則をカーネル内部に組み込んでしまうと融通が効かなくなって不便です。そのため,devfsが担っていた機能をユーザ領域のソフトウェアで実現するudevというツールが開発され,次第にdevfsに取って代っていくことになりました。

khttpd

もう1つ,このころのカーネルで目に付くのが,カーネルレベルでHTTPに対応しようというkhttpdです。khttpdのコードはlinux-2.3.18からnet/khttpdディレクトリに収められています。

$ ls linux-2.3.18/net/khttpd/
Config.in  accept.c       main.c          prototypes.h  security.c  structure.h  userspace.c
Makefile   datasending.c  make_times_h.c  rfc.c         security.h  sysctl.c     waitheaders.c
README     logging.c      misc.c          rfc_time.c    sockets.c   sysctl.h

linux-2.3が開発されていた1999年から2001年ごろはいわゆる「ITバブル」の時期で,さまざまな企業がインターネットに参入し,WWWが急速に普及し始めていた時期でした。

当時,さまざまな企業が「ITバブル」の波に乗ろうと,Webサービスに特化したようなサーバを開発し,その速度競争がカタログを賑わせていました。

いわゆる「Web 2.0」と呼ばれる動的なコンテンツが普及し始めたのが2005年ごろ,それ以前の時代は,静的なコンテンツをいかに高速にユーザに届けるかが重要なテーマでした。

「静的なコンテンツ」とはファイルシステム上に保存されたファイルです。それをネットワーク経由で可能な限り高速にユーザに送るためには,ユーザプロセスのhttpdを介するよりもカーネル自身が操作した方が速い,khttpdはそのようなアイデアで開発された機能で,カーネル自身がクライアントからのHTTPリクエストを解釈し,指定されたファイルを送信するように設計されています。

khttpdの考え方はそれなりに意味があったものの,⁠Web 2.0」の時代になると,ユーザのリクエストに応じて動的に生成したページを提供するサービスが主流となり,静的なコンテンツの提供に特化したkhttpdは次第に使われなくなりました。その結果,khttpdのコードはlinux-2.5の時代にソースコードから削除されました。

spinlock()の進捗

これは新機能ではないものの,前回指摘したカーネル内部での処理単位を細かくするためのspinlock()のコードは,linux-2.3シリーズを通じて増加しています。

ドキュメントでの言及も拾ってしまうものの,

$ find linux-2.3.0 -type f -a -exec grep -i spinlock {} \; | wc -l

としてソースコード中に出てくるspinlock()処理を数えてみたところ,linux-2.3.0では9392.3.18では12222.3.33では12942.3.51では16292.3.99-pre9では1868と,linux-2.3シリーズを通じて約2倍に増加しています。

ソースコードのサイズを調べたところ,linux-2.3.0が63M,linux-2.3.99-pre9は96Mで,linux-2.3シリーズを通じて約1.5倍の増加となり,spinlock()処理は新しいコードだけではなく,既存のコードが改訂される度にも追加されていったことがうかがわれます。

以上見てきたように,linux-2.3のシリーズは,開発期間が2年以上に及んだ2.1シリーズの反省から,当初は1年程度の開発期間で新しい安定版を公開するつもりだったものの,実際にはリリース直前まで新しいCPUへの対応が続き,ずるずると安定版の公開時期がずれていったようです。

2000年3月に公開された2.3.51の時点では,近いうちに安定版をリリースするつもりだったものの,次から次へと新機能を組み込んで収拾が付かなくなってしまった結果,きりの良い21世紀の最初(2001年1月)でリリースした,というところでしょうか。

一方,linux-2.3ではdevfsやkhttpdなど,伝統的なUNIXには存在しなかった新しい機能への取り組みが目に付きます。初期のLinuxはUNIXをお手本にさまざまな機能を開発してきました。それらUNIXの基本機能への追従はほぼ終了し,新しく未踏の領域に踏み込み始めたのがlinux-2.3シリーズだ,と言うことができそうです。


改めて現在の視点からlinux-2.3の開発状況を省みると,⁠急ぎすぎていたな」という印象を強く持ちます。その原因のひとつは本文中にも触れたように,この時期に生じていた「ITバブル」の影響でしょう。

Linuxを使ってApache httpdを動かし,MySQLをデータベースに,PythonやPerlでサービスを提供するスクリプトを書く,いわゆる「LAMP」が持てはやされていたのがこの時期だったように思います。膨大な数のLinuxサーバを使ってインターネット上の情報を収集,整理し,高精度で検索するGoogleが起業したのもこの時期でした。

実のところ,当時はLinusさん自身がTransmetaというIT系の新興企業に属していたため,⁠ITバブル」の影響をより強く受けていたように感じます。

ソースコードにはこのような外的要因は記録されないものの,LinuxにはKernel-MLに流れた膨大な量のメールアーカイブも存在します。それらをテキストマイニング的な手法で分析できれば,ソースコードの歴史を補完する重要な情報源になりそうです。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html