Re: [PATCH] 2.5.32-bug

From: Ingo Oeser (ingo.oeser@informatik.tu-chemnitz.de)
Date: Sat Aug 31 2002 - 07:00:08 EST


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/



This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:33 EST