public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Greg KH <greg@kroah.com>, linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: transport_class: BUG if we can't release the attribute container
Date: Wed, 2 Apr 2008 08:30:40 -0600	[thread overview]
Message-ID: <20080402143040.GU16451@parisc-linux.org> (raw)
In-Reply-To: <1207145753.3082.7.camel@localhost.localdomain>

On Wed, Apr 02, 2008 at 09:15:53AM -0500, James Bottomley wrote:
> On Tue, 2008-04-01 at 23:32 -0700, Greg KH wrote:
> > BUG_ON() should not do anything in the macro except test for a value, no
> > function calling.  I think checkpatch.pl checks for this...
> 
> Well, we can agree to differ on this.  The camp that wants no side
> effects for BUG_ON() does so in case they want to define it to be a nop.

That's one argument, but to me, the most important thing is that reading
the content of BUG_ON is unnecessary for understanding the function.

> OK ... your subsystem tree your call, I suppose.  How about the
> attached.

> -static inline int transport_container_unregister(struct transport_container *tc)
> +static inline void transport_container_unregister(struct transport_container *tc)
>  {
> -	return attribute_container_unregister(&tc->ac);
> +	int err = attribute_container_unregister(&tc->ac);
> +	BUG_ON(err);
>  }

What's wrong with:

	if (attribute_container_unregister(&tc->ac))
		BUG();

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-04-02 14:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-22 16:39 transport_class: BUG if we can't release the attribute container James Bottomley
2008-04-02  6:32 ` Greg KH
2008-04-02 14:15   ` James Bottomley
2008-04-02 14:30     ` Matthew Wilcox [this message]
2008-04-02 14:32       ` James Bottomley
2008-04-02 14:53         ` Greg KH
2008-04-02 15:05           ` James Bottomley
2008-04-02 14:32     ` Boaz Harrosh
2008-04-02 14:36       ` James Bottomley
2008-04-02 14:54     ` Greg KH

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=20080402143040.GU16451@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=greg@kroah.com \
    --cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox