8月版　リグレッションやChangeLogは不要？

上川純一
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
2007/9/3

linux-kernelメーリングリスト（以下LKML）かいわいで起きるイベントを毎月お伝えする、Linux Kernel Watch。諸事情により数カ月お休みをいただいておりましたが、今月から復活します。2007年7月までのLinuxカーネルメーリングリストで、どんなことが起きたか見てみましょう。

リグレッショントラッキングやChangeLogの意義は？

　ここ数カ月の間にLinusがリリースしたLinuxカーネルのリリースは2.6.21と2.6.22です。現在は2.6.23に向けた開発が進められているところです。

　カーネル2.6.21は4月26日にリリースされました。この開発の過程では、dyntickのマージ（注）などの大幅な変更がありました。

注：2007年3月版　Greg K-H、デバイスドライバ無料開発宣言！？を参照。

　2.6.21のリリースをアナウンスするメールの中には、Adrian Bunkによるリグレッショントラッキングの労をねぎらう文面がありました。しかしAdrian Bunkはそれを受けて、-rcのリグレッションのトラッキングでは、解決されないまま次のリリースに残るものが多く、労力に対する成果が少ないからもうやらないというメールを出しました。

　その理由として挙げられたのは、「-rcのテストをしている人数は多いのだが、それに対応できる開発者がいない」ということです。つまり、リグレッションが解決するペースよりも増えるペースの方が多く、トラッキングすることに意味がないのではないかという指摘でした。

　ここで、カーネルの安定度合いやリリース頻度についての議論が展開されました。Linusの論法は「頻繁にリリースする方がよいよ」というものです。実際、トラッキングしているからこそリグレッションはこんなに少ないのであり、Adrian Bunkのやっていることには意味がある、という意見が出されました。

　7月9日にはカーネル2.6.22がリリースされました。

　Linusはこのリリースに際して「ChangeLogなんて見ている人がいるのか？」という疑問を呈しました。どうせgit（注）を使えば作成できる情報だし、そもそもサイズが大き過ぎる（4Mbytesもある）というのです。この質問にはそれなりに反響があり、このままChangeLogを生成してほしいという意見が大半を占めました。gitを利用せずに最新のカーネルを利用しているユーザーはまだまだいるようです。

注：2005年5月版　BitKeeperからgitへ、ソースコード管理ツール大変更を参照。

　どちらのリリースとも-rc7まで出ており、それぞれ約2カ月半かかっています。

　現在はカーネル2.6.23のリリースに向けた開発が行われているところです。順調にいけば、9月中にリリースされるかもしれませんね。

関連リンク：
	カーネル2.6.21のChangeLog http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.21
	カーネル2.6.22のChangeLog http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22

新規追加のシステムコールあれこれ

　最近のソースコードを見てみると、いくつかのシステムコールが追加されています。Linux対応のプログラムを作成する上でシステムコールの追加は大きな影響を及ぼしますので、どういうものが追加されたのかを見てみましょう。

シグナルをファイルディスクリプタ経由で

　複数のファイルディスクリプタを効率よく監視するための仕組みであるepoll（注）を開発したDavide Libenziが、timerfdという仕組みを提案しました。

注：epollについては「全貌を現したLinuxカーネル2.6［第1章］」も参照のこと。

　タイマーを利用する際、通常アプリケーションはシグナルを割り込みとして受信しますが、この仕組みはシグナルをファイルディスクリプタ経由で受信するというものです。このおかげで、複数のタイマーイベントの通知を、read/poll/epollなどの通常のファイル読み込み操作として、ファイルディスクリプタ単位で受信することができるようになります。

　timerfdでは、新しいファイルディスクリプタを取得し、そのファイルディスクリプタに対してread()すると、タイマーの時間切れまで待ってくれます。もし複数回の割り込みが発生していたのであれば、最後にread()があった後からタイマーが満了した回数を、64ビットの整数値として返してくれるようになっています。

　こうして最初に提案されたtimerfdの仕組みに対し、Nicholas Miellが反論しました。既存のABI（Application Binary Interface）よりも機能が制限されている点が問題だというのです。安定したABIとして追加するのであれば、一般的に利用できるものになるべきであり、ほかのタイマーABIより機能が制限されるのはまずいだろうという意見でした。Linusも加わり、タイマーABIはどうあるべきかという議論が続きました。

　同時に、eventfdとsignalfdというシステムコールも追加されました。

　signalfdというのは、シグナルを受けた場合に通常の割り込み処理を行うのではなく、ファイルディスクリプタにシグナルを送信するものです。これで、非同期シグナルプログラミングではなく、ファイルディスクリプタに対してpoll()でPOLLINを待つということができるようになります。

　eventfdは、より単純に、シグナルではなくファイルI/Oのモデルでイベントの伝達を行うメカニズムです。

　これらは結果として、Linuxカーネル2.6.22-rc1で、次の3つのシステムコールとしてマージされました。

long signalfd(int ufd, sigset_t *user_mask, size_t sizemask); long timerfd(int ufd, int clockid, int flags, 　　　　　　　　　　const struct itimerspec *utmr); long eventfd(unsigned int count);

　しかし7月23日になって、Michael Kerriskがtimerfdのインターフェイスについて問題を提起しました。マニュアルページを作成していたところ、その機能が不十分であることが分かったというのです。具体的には、パラメータを1つ追加することを提案しました。

　このインターフェイスがいったん2.6.22としてリリースされた後に仕様を変更することについては懸念がありましたが、Andrew Mortonは「2.6.22.xと2.6.23としてリリースすればよいだろう」と提案しました。まだパッチが完成していない関係で修正はされていないようですが、今後どうなるのかが気になります。

fallocateシステムコールのその後は？

　Amit Aroraが提案したfallocateシステムコールは、posix_fallocate(int fd, off_t offset, off_t len)を実装するために必要な、Linuxカーネル側のインターフェイスです。

　posix_fallocateは、これから書き込むという意図を持って、事前にファイルのブロックを確保しておくことを指示するためのインターフェイスです。しかしglibcでエミュレーションされている実装では、指定されたブロックすべてにいったん書き込みをしてしまう仕組みになっており、パフォーマンスが出るようなものではありません。ファイルシステム側での支援が必要です。

　そのファイルシステム側の支援を提供するフレームワークがfallocateシステムコールとなります。8月の時点では、ocfs2とext4ファイルシステム向けのサポートがマージされているようです。

　ここで、fallocateに与えるパラメータの順番を変えるべきか、という議論がありました。s/390のサポートに当たって問題が生じたからです。しかし、s/390でのみ起こる問題なのに、全アーキテクチャに関してパラメータ渡しの順番を変更してしまう方法を取るよりも、s/390だけ例外処理をする方がよいだろうということになりました。そこでs/390だけシステムコールの渡し方を変更し、ラッパー関数を準備するという実装になりました。

　結果としてこれは、Linux 2.6.23-rc1でマージされました。

参考：
	s390のsys_fallocate用のラッパー arch/s390/kernel/sys_s390.c(sys_fallocate_wrapper)

1/2

Index Linux Kernel Watch　8月版 　リグレッションやChangeLogは不要？

Page 1 　リグレッショントラッキングやChangeLogの意義は？ 　新規追加のシステムコールあれこれ 　シグナルをファイルディスクリプタ経由で 　fallocateシステムコールのその後は？ 　 Page 2 　ナノ秒単位の設定が可能なutimensatシステムコール 　XenゲストOSもlguestもマージ 　ますます増える-stableツリー

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）