Messages in this thread |  | | Date | Sat, 31 Aug 2002 14:00:08 +0200 | From | Ingo Oeser <> | Subject | Re: [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/
|  |