On Thu, Dec 13, 2007 at 11:25:06PM -0800, Jeremy Fitzhardinge wrote:
> Dave Jones wrote:
> > On Fri, Dec 14, 2007 at 01:03:50AM +0100, Adrian Bunk wrote:
> >
> > > > #ifndef HAVE_ARCH_BUG
> > > > #define BUG() do { \
> > > > - printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
> > > > + printk(KERN_ERR "BUG: failure at %s:%d/%s()! (%s)\n",
> > > > + __FILE__, __LINE__, __FUNCTION__, print_tainted()); \
> > > > panic("BUG!"); \
> > > > } while (0)
> > > > #endif
> > > >...
> > >
> > > Note that this only changes a handful of architectures and most likely
> > > not the ones you are interested in.
> >
> > Hmm, it appears that I was mistaken, and we never did patch x86.
> > Which leaves me wondering if its worth it or not to patch BUG()
> > Anyways, here's the latest rev with the out-of-line changes as
> > suggested by Andi.
> >
> > init/main.c may not be the best place for the ool variant. suggestions?
> >
>
> lib/bug.c would be the place for architectures using
> CONFIG_GENERIC_BUG. x86 could be converted to use the BUG-trapping
> mechanism for WARN_ON like Power does, so it would be inherently out of
> line anyway.
The BUG()/WARN_ON() parts of my patch are becoming something of a rathole,
which I don't really have time to dig into right now, so I'm going to split
this up I think into mm/ additions, spinlockdebug additions, and bugon/warnon foo.
The three should be independant, and blocking the first two until I get
time to look at the third seems pointless.
Dave
--
http://www.codemonkey.org.uk
--
