8月版　波乱続きのReiser4、マージに向けて一歩前進？

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

ReiserFSの苦難

　現時点でLinuxカーネルにマージされているReiserFSは、バージョン3です。ReiserFSにはその次期バージョンであるReiser4もありますが、「Reiser4と激怒するLinuxカーネル開発者たち」でお伝えしたとおり、メインラインカーネルへのマージには至っていません。しかし、少し進展があったようです。

　まず、Reiser4が相変わらずメインラインのカーネルにマージされないことに業を煮やしたユーザーから、「いつマージされるのか？」という質問のメールが7月に何度かLKMLに投稿されました。Diego Callejaはそれに対応して、「WhyReiser4IsNotIn」（なぜReiser4がマージされていないのか）というまとめ文書を作りました。その趣旨は、「Reiser4は技術的には正しいことをしているが、政治的な理由があるからマージされないのではないか。われわれはユーザーとして便利に使えており、安定もしている。マージしてくれ」という議論への回答として、「Reiser4をレビューして修正を依頼した内容についてまだ修正されていない。そのためにマージされない」というものです。

　Hans Reiserはこれに対して「the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion」（kernelnewbies.orgのReiser4のマージについての公式見解について）というタイトルのメールで、「先日開発が表明されたext4（注）は簡単にマージされることになったのに、なぜReiser4はマージされないのか」として、不服を表明しました。

注：「新ファイルシステム「ext4」開発開始か」。

　今回も延々と水掛け論を繰り返して終わるのかと思いきや、「reiser4: maybe just fix bugs?」というスレッドで、Andrew Mortonから「ゆっくりではあるが、Reiser4のコードをレビューしている」というせりふが出てきました。以前議論になっていた部分については修正され、マージに向かって着実に進んでいるようです。

関連リンク：
	なぜReiser4がマージされていないのか http://wiki.kernelnewbies.org/WhyReiser4IsNotIn

request_firmwareで複数バージョンをどう扱う？

　近年、NIC（ネットワークインターフェイスカード）やSCSIカードなどのデバイスで、ファームウェアをデバイス側で保持せず、ドライバがファームウェアをロードしてからでないと動作しないデバイスが増えてきています。そのようなデバイスのためにファームウェアをロードする仕組みは統一されていません。現状では、ドライバごとにソースコードのヘッダファイルに16進数で書いた文字列を保持し、それを読み込んでロードするなどの手法が取られていました。

　最近では、この問題を解決するためにrequest_firmwareというインターフェイスがあります。これは、デバイスの駆動に必要なファームウェアデータをユーザー空間から取得するというものです。ドライバにファームウェアが格納されているファイルのファイル名を指定すると、ユーザー空間でhotplugがそのファイルを探してカーネルにロードするという仕組みです。

　具体的には、デバイスドライバが、

request_firmware(ファームウェアハンドル, ファームウェアファイル名, デバイス)

として関数を呼び出すと、ユーザー空間で動いているhotplugが、

/usr/lib/firmware

などを検索して該当するファイルを/sys/class/firmware/経由でロードします。

　ただし、「ファームウェアに複数のバージョンがあり、特定のデバイスでしか動かない場合に困る」とMartin Langerが指摘しました。bcm43xx（Broadcomの無線LANモジュール）がまさにそうしたデバイスだそうで、特定のハードウェアのバージョンに対して適切なファームウェアのバージョンがあるそうです。これを管理するためにAPIを拡張しよう、という提案をしたのですが、まだ実装の方法についての議論がうまくまとまっていないようです。

　ドライバを稼働させるために必要なインターフェイスなので、できるだけ安定して信頼できるように設計してほしいものですね。

参考：
	request_firmware hotplug interface カーネルソースのDocumentation/firmware_class/README

-stableの進ちょく

　7月も2.6.16と2.6.17系列が並行してメンテナンスが続けられています。

• 2.6.16.24（7月6日）
  　・コアダンプ処理のセキュリティフィックス（CVE-2006-2451）
• 2.6.16.25（7月14日）
  　・/procの脆弱性の修正（CVE-2006-3626）
• 2.6.16.26（7月15日）
  （間違えて2.6.16.25としてコミットしてしまったバージョン）
  　・/procの脆弱性の修正による制限を少し緩める
• 2.6.16.27（7月17日）
  　・ftdi_sioシリアルドライバのDoS（CVE-2006-2936）
  　・ipv6の修正

• 2.6.17.4（7月6日）
  　・コアダンプ処理のセキュリティフィックス（CVE-2006-2451）
• 2.6.17.5（7月14日）
  　・/procの脆弱性の修正（CVE-2006-3626）
• 2.6.17.6（7月15日）
  　・/procの脆弱性の修正による制限を少し緩める
• 2.6.17.7（7月24日）
  　・XFSファイルシステムのデータ不正の修正
  　・v4l/dvbのいくつかの修正
  　・ftdi_sioシリアルドライバのDoS（CVE-2006-2936）
  　・ALSAの修正
  　など46パッチ

2/2

Index Linux Kernel Watch　8月版 　波乱続きのReiser4、マージに向けて一歩前進？

Page 1 　カンファレンス会場からこぼれ出てきた話題 　Xenマージへの道のり Page 2 　ReiserFSの苦難 　request_firmwareで複数バージョンをどう扱う？ 　-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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）