On Sun, 06 Jan 2008 12:44:56 +0100Well, the main point were to use the boolean type instead of an integer...
Richard Knutsson <ricknu-0@xxxxxxxxxxxxxx> wrote:
Arjan van de Ven wrote:
From: Olof Johansson <olof@xxxxxxxxx>
Introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Signed-off-by: Olof Johansson <olof@xxxxxxxxx>
Cc: <linux-arch@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
include/asm-generic/bug.h | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
Index: linux-2.6.24-rc6/include/asm-generic/bug.h
===================================================================
--- linux-2.6.24-rc6.orig/include/asm-generic/bug.h
+++ linux-2.6.24-rc6/include/asm-generic/bug.h
@@ -31,14 +31,19 @@ struct bug_entry {
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); }
while(0) #endif
-#ifndef HAVE_ARCH_WARN_ON
+#ifndef __WARN
+#define __WARN() do
{ \
+ printk("WARNING: at %s:%d %s()\n",
__FILE__, \
+ __LINE__,
__FUNCTION__); \
+
dump_stack();
\ +} while (0) +#endif
+
+#ifndef WARN_ON
#define WARN_ON(condition)
({ \ int
__ret_warn_on = !!(condition); \
What about using a boolean for __ret_warn_on, which then let us
remove the '!!'?
is iffy.. like what happens if an u64 is cast to a boolean?
No matter what the final assembly code will need to be the same
You mean because in that case it would be '!= NULL', do you? Sorry, do not see your point here.(btw, wouldn't 'var != 0' actually be the proper semantic instead of playing with '!'s?)
no because var could be a pointer for example...