lkml.org 
[lkml]   [2002]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.5.32-bug
Hi Rusty,

On Fri, Aug 30, 2002 at 10:39:12PM +0100, Russell King wrote:
> This patch appears not to be in 2.5.32, but applies cleanly.
>
> This patch moves BUG() and PAGE_BUG() from asm/page.h into asm/bug.h.
>
> We also fix up linux/dcache.h, which included asm/page.h for the sole
> purpose of getting the BUG() definition.
>
> Since linux/kernel.h makes use of BUG(), asm/bug.h is included there
> as well.
> --- orig/include/asm-cris/bug.h Thu Jan 1 01:00:00 1970
> +++ linux/include/asm-cris/bug.h Sun Jan 6 11:46:09 2002
> @@ -0,0 +1,12 @@
> +#ifndef _CRIS_BUG_H
> +#define _CRIS_BUG_H
> +
> +#define BUG() do { \
> + printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
> +} while (0)
> +
> +#define PAGE_BUG(page) do { \
> + BUG(); \
> +} while (0)
> +
> +#endif

These kind of implementation of BUG() is not very useful. Callers
of BUG() and BUG_ON() assume, that the thread is aborted and do
nothing to fixup after BUG().

That makes sense, because that way BUG reduces code size and
simplifies actual code by omitting the error handling for errors
which are in the in kernel caller.

So please consider using panic() instead of printk() here to
encourage fixing of BUGs.

Maybe we should even officially define, whether BUG() is an
execution barrier or not.

I would vote for YES, because of code size reductions under this
assumption.


Thanks & Regards

Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [from the cache]
©2003-2011 Jasper Spaans