From: Dean Nelson <dcn@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 2/4] SGI Altix cross partition functionality
Date: Thu, 29 Jul 2004 18:36:23 +0000 [thread overview]
Message-ID: <20040729183623.GA5252@sgi.com> (raw)
In-Reply-To: <20040616163514.GB27891@sgi.com>
On Wed, Jun 16, 2004 at 06:28:22PM +0100, Christoph Hellwig wrote:
> > + XP_ASSERT(ch_number >= 0 && ch_number < XPC_NCHANNELS);
> > + XP_ASSERT(payload_size != 0 && nentries != 0);
> > + XP_ASSERT(func != NULL);
> > + XP_ASSERT(assigned_limit != 0 && idle_limit <= assigned_limit);
>
> Please use BUG_ON()
As you may have seen, on the lkml I asked for comments on the value of
creating a conditionally compiled version of BUG_ON(). I called it
DBUG_ON() and modeled it after dev_dbg(), which is conditionally
compiled based on #ifdef DEBUG. The subject of the lkml thread is:
[RFC] replace assorted ASSERT()s by something officially sanctioned
The feedback I got raised two issues:
1. For a large number of ASSERT()s, WARN_ON() would be a better
fit than BUG_ON().
2. The granularity of #ifdef DEBUG is too course. A finer
granularity on the driver level makes more sense. (This
also holds true for dev_dbg()).
To the first, I suggested that a conditionally compiled version of WARN_ON()
be added as well, i.e., DWARN_ON().
To the second, I didn't have much to say other than to agree. (I was hoping
the community would chime in with a community acceptable policy on this
matter.)
I still feel strongly that there is a need for a conditionally compiled
version of BUG_ON and WARN_ON() for the reason given in my RFC. (And I
really don't care what the name of the macro is.)
I haven't pushed any further on the matter because of the underwhelming
feedback to my RFC.
I'm bringing all of this to your attention because of the existing
XP_ASSERT()s in my proposed patches. I've dealt with the ones that
deserved to be BUG_ON()s. But I've got a lot of them that really (in
my opinion) should be conditionally compiled in. They really are only
necessary while in a debug mode.
So, I was wondering if you would accept my #define'ng a local DBUG_ON()
(or XP_ASSERT()) based on BUG_ON() and whether #ifdef DEBUG (or #ifdef
XP_DEBUG) is true?
Thanks,
Dean
next prev parent reply other threads:[~2004-07-29 18:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-16 16:35 [PATCH 2/4] SGI Altix cross partition functionality Dean Nelson
2004-06-16 17:28 ` Christoph Hellwig
2004-06-16 20:22 ` Keith Owens
2004-07-29 18:36 ` Dean Nelson [this message]
2004-08-31 19:22 ` [PATCH 2/4] SGI Altix cross partition functionality (1st revision) Dean Nelson
2004-09-01 10:19 ` Robin Holt
2004-09-04 11:12 ` Christoph Hellwig
2004-09-04 11:15 ` Christoph Hellwig
2004-09-04 16:35 ` Russ Anderson
2004-09-04 16:55 ` Christoph Hellwig
2004-09-04 16:57 ` Christoph Hellwig
2004-09-05 11:45 ` Robin Holt
2004-12-20 18:45 ` Dean Nelson
2004-12-21 12:20 ` Dean Nelson
2005-01-05 11:35 ` Christoph Hellwig
2005-01-05 11:35 ` Christoph Hellwig
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=20040729183623.GA5252@sgi.com \
--to=dcn@sgi.com \
--cc=linux-ia64@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.