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.har...@sabayonlinux.org>
---
kerncompat.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kerncompat.h b/kerncompat.h
index f370cd8..79661f5 100644
--- a/kerncompat.h
+++ b/kerncompat.h
@@ -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); \
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
