2.4.xカーネルとmkfs.jffs2

昨日のCE Linux Forum の Technical Jamboree 12の中で、
「そろそろ2.4系も卒業ですよね?」
「いやいや、組込み系の人は保守的な方が多いですから」
という話があったが、それに関連して。

JFFS2用のディスクイメージを作成するmkfs.jffs2コマンドがビルドできないという報告が立て続けにあった。
http://lists.infradead.org/pipermail/linux-mtd/2006-November/016811.html
http://lists.infradead.org/pipermail/linux-mtd/2006-December/016999.html

原因は、XATTRサポートを入れたときにPOSIX-ACL関連のファイルをインクルードするようにしていて(#include <sys/acl.h> を追加)、古めの開発環境では「sys/acl.hなんてネーヨ!」と怒られてしまうというもの。
で、これの対策の正解は mkfs.jffs2 をビルドする時に WITHOUT_XATTR=1 というモノをつける。

% make WITHOUT_XATTR=1
とするわけだ。
これで、XATTRやPOSIX-ACL関連の機能を含まなくなる。
2.4.xカーネルを前提とした枯れたtoolchainでは sys/acl.h が無いこともあるので、これで回避することができる。

余談だが、最初、この問題がMLで報告された時に「これは何のための機能かわからない」とか書いてあった時には思わずのけぞったが、まぁ、分野の違うところで話をする時にはそれくらいの配慮があって然るべきだろう。

あと、豆知識。
XATTRを取得する時に、XATTRの種類によっては on-disk のフォーマットを変換してからユーザ空間に渡すものがある。例えば、POSIX-ACLがそう。
David Woodhouseは mkfs.jffs2 の XATTR 関連のコードについて以下のように言っているが、

Actually, I'm not entirely sure what this code is doing at all -- isn't it interpreting on-disk xattrs representing ACLs assuming that they're in the same format as ext3 uses? If you use mkfs.jffs2 on a big-endian system, actually reading _from_ a jffs2 filesystem, does it do the right thing? What about from other file systems?

KaiGai-san?

正解は、ファイルシステムやCPUのエンディアンの違いに関わらず、ユーザ空間にACL情報を返却する前に共通のフォーマットに変換するから、アプリは特に気にする必要がない。

なので、私は mkfs.jffs2 のパッチを書く必要がない :-)