@naota344の今週のLKML(範囲拡大してるけど)

(テストとかいろいろあってお休みしてたけれど落ち着いてきたのでただいま!たまってたネタがあるので「今週」ではなく「今月」ぐらいになってます)

今週は

  • [RFC/PULL 00/11] introduce export.h; reduce module.h usage
  • [RFC] btrfs send and receive

[RFC/PULL 00/11] introduce export.h; reduce module.h usage

http://permalink.gmane.org/gmane.linux.kernel.cross-arch/10519

カーネルモジュールを作るさいにincludeするmodule.hというヘッダがあります。このmodule.hを直接includeしているヘッダだけでも34もあり、module.hへの変更がそれらヘッダに影響し、さらにそれをincludeしているヘッダ・コードに影響し……ということでmodule.hへの変更はカーネルのほとんど全てのファイルに影響して全てをコンパイルしなおすことになってしまいます。

これはうまくありませんね……。なんとかこの依存関係を減らそう、というのがこのpatchになります。注目しているのはmodule.hの中のEXPORT_SYMBOL/THIS_MODULEという…まあその名のとおりに指定された「シンボル」(関数とか)をexportするようなマクロです。このEXPORT_SYMBOL/THIS_MODULEだけを必要とするモジュールではないようなコードがたくさんあるので、この2つをexport.hとい新しいヘッダに移して、これらしか必要としないものについてはexport.hを読みこむようにする、という解決策をとっています。

さて…これで実際どの程度高速になるのか…という疑問が残ります。

Ingoの実験 https://lkml.org/lkml/2011/5/28/60

このもともとのIngoの実験によれば約2%の高速化がされているようですし、

http://permalink.gmane.org/gmane.linux.kernel.cross-arch/10537

またプリプロセッサの出力が0.5%減少していることから、少なくとも0.5%程度は速くなるのではないかと思われます。

http://permalink.gmane.org/gmane.linux.kernel.cross-arch/10539

まあ、これはかなりのビルドへの影響を出しそうなpatchなので…linux-nextには入ってそのまま様子見の感じのようですね。

[RFC] btrfs send and receive

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/12318

btrfsのバックアップ/レプリケーション機能をつけようとするRFCが出ていました。

そもそもZFSのsend/recvから既存のバックアップとどう違うのだろう…と思っていましたが

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/12504

を読んで、inode番号の保持やスナップショット・サブボリューム・reflinkなどを含めると既存のバックアップツールでは難しいのですね。実験的なファイルシステムのbtrfsですから…バックアップ機能がついて安心して開発できるようになるといいですね。