Re: [PATCH] Silence 'ignoring return value' warnings indrivers/video/aty/radeon_base.c
From: Arjan van de Ven
Date: Wed May 07 2008 - 00:37:48 EST
On Tue, 6 May 2008 21:23:14 -0700
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 6 May 2008 21:15:52 -0700 Arjan van de Ven
> <arjan@xxxxxxxxxxxxx> wrote:
>
> > On Tue, 6 May 2008 21:12:33 -0700
> >
> > > > can we make it a WARN_ON() as well? that way we'll see it in
> > > > various kerneloops.org stats etc etc.. and we also get a nice
> > > > backtrace for free to go with it....
> > > >
> > > > (rationale: users tend to not read their dmesg much, but
> > > > WARN_ON()'s do get noticed)
> > >
> > > OK by me, although if we're going to do much more of this it
> > > might be time to add a WARN_ON which takes (fmt, args...).
> >
> > totally; I was just talking to some others about doing just this.
>
> The challenge will be to minimise the code footprint.
the meat of WARN_ON() is already out of line; so all the vararg stuff
is just going to be one function out of line, if we really care about
the last 20 bytes we can even implement WARN_ON() using an empty string.
I suspect it's not all that bad.
(but gcc is still churning, so no hard data yet)
> otcompletelyoh, perhaps we could generate a backtrace from within
> printk() itself for when it sees messages which have KERN_ERR or some
> other suitably-chosen (and probably configurable) facility level.
interesting thought. Only thing is that this won't give the option to
have a condition there, or to compile it out for those folks who care
about squeezing the last bytes out by disabling such debug messages.
>
> That'll generate false positives and will reveal dubious choices, but
> we can fix those up.
I'm not all that worried about that; if we introduce a new flag that is
it'll be explicit and fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/