>> However, I would not be surprised to find that there are places in
>> the kernel where if an assumption proves to be false, we would
>> need to abort the operation that led to that function, and I would
>> see something like the following being used:
> kassert() is a nop in release builds...
That appears to be a contested viewpoint. The current voting is 8
people in favour of kassert always evaluating its arguments and 6 in
favour of it not doing so if its disabled - and, as previously stated,
I'm in the latter group.
> ...so kassert() can't be used like this.
> --> replace with
> if(!cond) {
> kassert(FALSE);
> return;
> }
That has the problem that it doesn't print the condition if its
enabled. The following would be better:
Q> #if (!cond) {
Q> kassert(cond);
Q> goto DealWithError;
Q> }
Replace the goto with a return if no special handling is required,
otherwise DealWithError deallocates any memory leaks or the like that
would be left behind.
> I don't think that special purpose macros should be added to
> <linux/kdebug.h>, instead it provides a framework and you must
> use #ifdef CONFIG_KDEBUG if you need anything special. [our NT
> driver: 1700 ASSERT() macros and 95 #ifdef BLD_DEBUG for special
> checks such as debug only variables, memory corruption tests, ...]
One problem is that I don't see a kdebug.h file in the 2.2.10 tree,
other than the SPARC specific ones in asm-sparc{,64}/kdebug.h and, as
a result, your comments are less than helpful.
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/