>> There is also the fact that by its nature, assertion checking
>> makes most of the standard oops report redundant as, if
>> kassertoops was to be used, the exact circumstances would be
>> known in advance. It would therefore make more sense to have two
>> separate oops functions, one to deal with the current oops
>> events, and a second to deal with an oops caused by a
>> kassertoops() call.
> Maybe call panic() or similar, instead of oops-ing?
True - I've used panic() in the latest version.
>> Here's the corrected version:
>> +#ifdef DEBUG
> 'DEBUG' is far too general. __USING_KASSERT?
How about a kernel configuration option - or, rather, two such
options. The enclosed patch (relative to the 2.2.10 kernel) adds
CONFIG_KERNEL_ASSERT and CONFIG_KERNEL_ASSERT_OOPS to the alpha,
arm and i386 ports in the "Kernel hacking" section, together with
the latest version of the kassert() and kassertoops() macros and
the relevant COnfigure.help documentation.
>> +#else
>> +#define kassert(cond) (void) abs(cond)
>> +#define kassertoops(cond) (void) abs(cond)
>> +#endif
> Any code depending on assert evaluating the condition is broken
> IMHO.
IMHO also, but the general concensus appears to be in favour of it.
I've put an '#if 1'-#else-#endif block in the code, defaulting to
not evaluating, but changing the '#if 1' line to '#if 0' inverts that.
> Doing so breaks an important feature of assert: it evaluates to
> nothing when disabled. Your above example violates the principle
> of least surprise; instead, it should be ((void)0)
Instead, it should be...
Q> #define kassert(cond)
...which just chops the whole line out.
> Once it does that, please do submit it to the Upper Penguins.
One last round of checking before I do so...
--- linux-2.2.10/include/linux/kassert.h~ Thu Jan 1 01:00:00 1970
+++ linux-2.2.10/include/linux/kassert.h Thu Jun 24 14:32:43 1999
@@ -0,0 +1,63 @@
+/*
+ * Include definitions for kernel assertion checking
+ */
+
+#ifndef __KASSERT_H__
+#define __KASSERT_H__
+
+#ifdef CONFIG_KERNEL_ASSERT
+
+/*
+ * Choose the reporting level to use
+ */
+
+# define REPORT_LEVEL KERN_DEBUG
+
+/*
+ * Define the kassert() macro
+ */
+
+# define kassert(cond) \
+ if (cond) { \
+ /* Do nothing */; \
+ } else { \
+ printk( REPORT_LEVEL "ASSERTION FAILURE: %s line %u: %s\n" \
+ "Assertion = (%s)\n", \
+ __FILE__, __LINE__, __FUNCTION__, #cond ); \
+ }
+
+/*
+ * Define the kassertoops() macro appropriately
+ */
+
+# ifdef CONFIG_KERNEL_ASSERT_OOPS
+
+# define kassertoops(cond) \
+ if (cond) { \
+ /* Do nothing */; \
+ } else { \
+ printk( REPORT_LEVEL "ASSERTION FAILURE: %s line %u: %s\n" \
+ "Assertion = (%s)\n", \
+ __FILE__, __LINE__, __FUNCTION__, #cond ); \
+ panic("Kernel assertion failure"); \
+ }
+
+# else
+
+# define kassertoops(cond) kassert(cond)
+
+# endif
+
+#else
+
+# if 1
+# define kassert(cond)
+# else
+# define kassert(cond) (void) abs(cond)
+# endif
+
+# define kassertoops(cond) kassert(cond)
+
+#endif
+
+#endif
--- linux-2.2.10/arch/i386/config.in~ Mon Apr 26 21:49:17 1999
+++ linux-2.2.10/arch/i386/config.in Thu Jun 24 14:06:00 1999
@@ -199,5 +199,11 @@
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
+bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT
+if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then
+ bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS
+fi
+
endmenu
--- linux-2.2.10/arch/i386/defconfig~ Mon Apr 12 21:12:57 1999
+++ linux-2.2.10/arch/i386/defconfig Thu Jun 24 13:45:26 1999
@@ -349,3 +349,4 @@
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_KERNEL_ASSERT is not set
--- linux-2.2.10/arch/alpha/config.in~ Sat May 22 21:41:37 1999
+++ linux-2.2.10/arch/alpha/config.in Thu Jun 24 14:05:43 1999
@@ -285,4 +285,11 @@
fi
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
+bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT
+if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then
+ bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS
+fi
+
endmenu
+
--- linux-2.2.10/arch/alpha/defconfig~ Sat Jun 12 19:52:51 1999
+++ linux-2.2.10/arch/alpha/defconfig Thu Jun 24 13:50:00 1999
@@ -331,3 +331,4 @@
#
CONFIG_MATHEMU=y
# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_KERNEL_ASSERT is not set
--- linux-2.2.10/arch/arm/config.in~ Thu Jan 14 18:29:28 1999
+++ linux-2.2.10/arch/arm/config.in Thu Jun 24 14:06:35 1999
@@ -217,4 +217,11 @@
bool 'Debug kernel errors' CONFIG_DEBUG_ERRORS
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+
+bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT
+if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then
+ bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS
+fi
+
endmenu
+
--- linux-2.2.10/arch/arm/defconfig~ Thu Feb 25 18:46:46 1999
+++ linux-2.2.10/arch/arm/defconfig Thu Jun 24 13:51:03 1999
@@ -263,3 +263,4 @@
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y
+# CONFIG_KERNEL_ASSERT is not set
--- linux-2.2.10/Documentation/Configure.help~ Mon Jun 14 03:54:06 1999
+++ linux-2.2.10/Documentation/Configure.help Thu Jun 24 14:04:30 1999
@@ -9762,6 +9762,23 @@
keys are documented in Documentation/sysrq.txt. Don't say Y unless
you really know what this hack does.
+Kernel assertion checking
+CONFIG_KERNEL_ASSERT
+ If you say Y here, then any assertions made in the kernel with the
+ kassert() or kassertoops() macros will be checked at runtime. This
+ can help in locating kernel bugs, since any messages resulting from
+ this will indicate assumptions made by the programmers that are not
+ in fact true.
+
+Allow OOPS on assertion failure
+CONFIG_KERNEL_ASSERT_OOPS
+ If you say Y here, then any assertions made in the kernel with the
+ kassertoops() macro that fail will result in an OOPS occurring once
+ the assertion failure has been reported.
+
+ If you say N here, then the kassertoops() macro will behave the same
+ as the kassert() macro, and no OOPS will occur in this event.
+
ISDN subsystem
CONFIG_ISDN
ISDN ("Integrated Services Digital Networks", called RNIS in France)
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/