[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080205153752.243d3b63.akpm@linux-foundation.org>
Date: Tue, 5 Feb 2008 15:37:52 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: adobriyan@...ru, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Whine about suspicious return values from module's
->init() hook
On Wed, 6 Feb 2008 09:48:10 +1100
Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Tuesday 05 February 2008 17:24:57 Andrew Morton wrote:
> > On Tue, 5 Feb 2008 17:08:37 +1100 Rusty Russell <rusty@...tcorp.com.au>
> wrote:
> > > On Tuesday 05 February 2008 14:53:18 Andrew Morton wrote:
> > > > That risks killing previously-working setups. WARN_ON is sufficient.
> > >
> > > I disagree. WARN_ON is useful for developers, but they can handle
> > > BUG_ON, too.
> >
> > For developers, BUG_ON has zero benefit relative to WARN_ON.
> >
> > For non-developers, BUG_ON has large disadvantages relative to WARN_ON.
> >
> > It's a no-brainer.
>
> For non-developers, WARN_ON is a noop.
Oh.. Rusty. The mailing list and bugzilla are *full* of WARN_ON reports
from testers. Your statement is empirically wrong.
> For developers, WARN_ON is often a noop.
And from developers.
> BUG_ON() will make us fix it in return for short-term pain.
Pain to our users and testers. People upon whom we are very dependent and
to whom we are hugely indebted. People who I have to spend a lot of time
defending from the likes of you!
> WARN_ON() wont,
> in return for less pain. It's mildly better than nothing, but not worth the
> patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists