linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: dhowells@redhat.com, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/7] Add conditional oopsing with annotation
Date: Tue, 20 Dec 2011 15:34:43 +0000	[thread overview]
Message-ID: <14686.1324395283@redhat.com> (raw)
In-Reply-To: <20111218080205.GA4144@elte.hu>

Ingo Molnar <mingo@elte.hu> wrote:

> Hm, what about WARN_ON()s?

Good point.

> BUG()s are generally a poor way of reporting bugs.

Sometimes you can't continue, and there's no way you can know how to clean up
- after all, if you see values you don't expect, how can you handle them?

> 1) BUG_ON() is a well-known pattern. Changing it to the inverted
>    assert() braindamage is going to cause confusion years down
>    the road.

In my opinion, BUG_ON() is usually inverted from what it should be.
Frequently, it seems to be bugging on an inverted condition.

assert() is generally well known from userspace.  You lay out your
expectations with asserts.  An assert says "I expect this value to comply with
this condition" - such as a value being in a specific range.  Generally I
would turn them on whilst debugging stuff, and suppressing them at other
times, but I'd leave BUG[_ON]() and WARN[_ON]() enabled.

> 2) The '>,0' syntax is ugly.

And works rather well.  I've been using it for a while now in the kernel quite
successfully.

> Why don't we simply extend the *existing* primitives with a 
> 'verbose' variant that saves the text string of the macro using 
> the '#param' syntax, intead of modifying the usage sites with a 
> pointless splitting along logical ops?

You've completely missed the point.  Go back and re-read the description.

> Doing that would also remove the rather pointess ANNOTATED_() 
> prefix, which is like totally uninteresting in the actual usage 
> sites. WARN()s want to be as short, obvious and low-profile as 
> possible.

You need to distinguish annotated errors/warnings from non-annotated ones...
unless you're planning on completely converting all the BUG/WARN calls in one
patch?

You could call it BUG_ON_VERBOSE() - but verbose BUG_ON already exists as a
concept within the kernel, so I chose a different name.


Note that my preferred mechanism would be to permit the cut-here line to be
emitted early, and have the one that's emitted by the BUG handler then
suppressed, but Linus doesn't like that.  I think it would be preferable to
trying to pass a va_list argument through the exception handler.

David

      parent reply	other threads:[~2011-12-20 15:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 14:13 [PATCH 1/7] Add conditional oopsing with annotation David Howells
2011-12-16 14:14 ` [PATCH 2/7] Make shrink_dcache_for_umount_subtree() use ANNOTATED_BUG() David Howells
2011-12-16 14:14 ` [PATCH 3/7] Add assertion checking macros David Howells
2011-12-16 14:14   ` David Howells
2011-12-16 21:36   ` Andi Kleen
2011-12-20 15:38   ` David Howells
2011-12-16 14:14 ` [PATCH 4/7] FS-Cache: Use new core assertion macros David Howells
2011-12-16 14:14 ` [PATCH 5/7] CacheFiles: " David Howells
2011-12-16 14:14 ` [PATCH 6/7] AFS: " David Howells
2011-12-16 14:14   ` David Howells
2011-12-16 14:14 ` [PATCH 7/7] RxRPC: " David Howells
2011-12-16 14:14   ` David Howells
2011-12-17 19:15 ` [PATCH 1/7] Add conditional oopsing with annotation Mike Frysinger
2011-12-17 19:15   ` Mike Frysinger
2011-12-18  8:02 ` Ingo Molnar
2011-12-20 15:34 ` David Howells [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14686.1324395283@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).