以前のエントリーで、BtrfsにBUG_ONマクロが散見されることについて書いた。この件について、#btrfsのIRCチャネルでBUG_ONについて質問してみた。でも、IRCではほしい答えが得られなかったので、Btrfsの開発メーリングリストに質問を投げてみた。 On Removing BUG_ON macros http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06664.html This is a question I've posted on the #btrfs IRC channel today. hyperair adviced me to contact with Josef Bacik or Chris Mason. So, I post my question to this maling list.
タイトルはちょっと大げさだけど、btrfs-unstableブランチとメインラインに動きがあったので、今回はその紹介。 実は、Btrfsの開発ブランチである git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable は今年の7月中旬頃から全然更新されない状況が続いていた。Btrfsのメーリングリストには、日々様々なパッチが投稿されている。Btrfsの開発者のChris Masonさんはメーリングリスト上では返事もしている。にも関わらず。 コミュニティからは、btrfs-unstableブランチはかなり古いので、別のツリーがあるのか?といった質問をされる始末。ちなみに、これに対して誰も返事していない。僕も誰か返事してくれるかな、と期待していたのだれども。 Re: Inode to bdi issue? Tomasz
BUG_ONマクロは、Linuxカーネルにおいて、引数に与えられた式を評価した結果が真となることが想定されない箇所(つまり、真ならバグ)で使われる。簡単に言うと、Cのassertのようなもの。ただし、assertよりもきつくて、BUG_ONの引数が真になると、カーネルパニックを引き起こす。つまり、BUG_ONの引数が真になったらカーネルが即死なので、利用には十分に気をつけるべきマクロである。 Btrfsのコードを読み始めて薄々感じていたけれども、BtrfsではこのBUG_ONマクロが過剰なまでに多く使われている。 他のファイルシステムと比べて、どの程度過剰か数字を取ってみた。(数字は、最新のメインラインより計測。tail -n +2は、findの結果の1行目にfsが含まれることで、xargs grepで2重に計測してしまうのを防ぐトリック。BUILD_BUG_ONは、無害とみなした。) 枯
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く