@@ -233,9 +233,19 @@ static inline long IS_ERR(const void *ptr)
#define kstrdup(x, y) strdup(x)
#define kfree(x) free(x)
-#define BUG_ON(c) assert(!(c))
-#define WARN_ON(c) assert(!(c))
+#define BUG_ON(c) do { \
+ if (c) { \
+ fprintf(stderr, "BUG_ON!\n"); \
+ assert(!(c)); \
+ } \
+} while (0)
+#define WARN_ON(c) do { \
+ if (c) { \
+ fprintf(stderr, "WARN_ON!\n"); \
+ assert(!(c)); \
+ } \
+} while (0)
#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
I'm providing this patch as an example of how to expand the BUG_ON/WARN_ON macros to provide more information or extra capabilities. Josef Bacik has been working on working with a user on IRC to recover data from a btrfs volume, and the 'work-in-progress' solution involved expanding the BUG_ON/WARN_ON macros in a different method that would lose the information on where the BUG_ON/WARN_ON occured. When the macro is structured like this patch, it will still provide the location of the BUG_ON/WARN_ON in the code. This patch also highlights that BUG_ON and WARN_ON are the same thing in btrfs-progs. All WARN_ONs are treated the same as BUG_ONs, and the program is halted. Should we convert all our btrfs-progs WARN_ONs to BUG_ONs to allow us to implement a true WARN_ON functionality? Signed-off-by: Mitch Harder <mitch.harder@sabayonlinux.org> --- kerncompat.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)