@naota344の今週のLKML(範囲拡大してるけど)
(テストとかいろいろあってお休みしてたけれど落ち着いてきたのでただいま!たまってたネタがあるので「今週」ではなく「今月」ぐらいになってます)
今週は
[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ですから…バックアップ機能がついて安心して開発できるようになるといいですね。