LinuxカーネルHack: BtrfsのBUG_ONマクロ撲滅運動
以前のエントリーで、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. Here are my post on the IRC: Actually, I want to remove BUG_ON(ret) around the Btrfs code. The motivation is to make the Btrfs code more robust. First of all, is this meaningless? For example, there are code like the following: struct btrfs_path *path; path = btrfs_alloc_path(); BUG_ON(!path); This is a frequenty used pattern of current Btrfs code. A btrfs_alloc_path()'s caller has to deal with the allocation failure instead of using BUG_ON. However, (this is what most interesting thing for me) can the caller do any proper error handlings here? I mean, is this a critical situation where we cannot recover from? -- Yoshinori Sano <yoshinori.s...@gmail.com>
Re: On Removing BUG_ON macros
そしたら、Josefさんから返事が来た。単にlazyだと。。どんな風に返事しようかな。
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06666.html
No we're just lazy ;). Tho making sure the caller can recover from getting -ENOMEM is very important, which is why in some of these paths we just do BUG_ON since fixing the callers is tricky. A good strategy for things like this is to do something like static int foo = 1; path = btrfs_alloc_path(); if (!path || !(foo % 1000)) return -ENOMEM; foo++; that way you can catch all the callers and make sure we're handling the error all the way up the chain properly. Thanks, Josef