All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Michael Wu <flamingice@sourmilk.net>
Cc: Michael Buesch <mb@bu3sch.de>, Daniel Drake <dsd@gentoo.org>,
	johannes@sipsolutions.net, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
Date: Thu, 4 Oct 2007 14:15:16 -0400	[thread overview]
Message-ID: <20071004181516.GH6037@tuxdriver.com> (raw)
In-Reply-To: <200710041311.37997.flamingice@sourmilk.net>

On Thu, Oct 04, 2007 at 01:11:33PM -0400, Michael Wu wrote:
> On Thursday 04 October 2007 11:19, John W. Linville wrote:
> > > The reason why BUG_ON exists is to catch bugs that happen, although
> > > they Should Never Happen (tm) ;)
> >
> > Precisely.

> No really, this bug will never happen. This is function is merely a helper 
> function which is called from interface removal code (where the interface 
> *has* to be down) or from changing the interface type (which ensures that the 
> interface is down first). There are an unlimited number of bugs which Should 
> Never Happen. That doesn't mean we should start adding BUG_ONs for every 
> single one of them. That gives some sort of protection against cosmic rays 
> flipping bits, but down here on earth, it's bloat.

Falling back on bloat as an argument against a BUG_ON in a
configuration path seems a bit weak. :-)

Programming with assertions (and BUG_ON is a form of that) is
generally a good practice.  Almost any book or other source on
good programming practices will agree.  Yes, it can be overdone.
But I don't really think that is the case here, since the check is
relatively inexpensive and the consequence should it ever *somehow*
happen could be a something wierd (crash, corruption, etc) w/o any
other indication of what occured.

Anyway, the point is probably moot in this case if there is no great
objection to the alternative patch I proposed.

John
-- 
John W. Linville
linville@tuxdriver.com

  reply	other threads:[~2007-10-04 18:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-04 11:33 [PATCH] mac80211: Fix TX after monitor interface is converted to managed Daniel Drake
2007-10-04 14:34 ` Michael Wu
2007-10-04 15:06   ` Michael Buesch
2007-10-04 15:14     ` Michael Wu
2007-10-04 15:14       ` Michael Wu
2007-10-04 15:19     ` John W. Linville
2007-10-04 17:11       ` Michael Wu
2007-10-04 18:15         ` John W. Linville [this message]
2007-10-04 21:16           ` Michael Wu
2007-10-04 21:31           ` Roland Dreier
2007-10-04 22:13             ` John W. Linville
2007-10-04 18:12   ` Johannes Berg
2007-10-04 15:54 ` Stephen Hemminger
2007-10-04 16:56   ` Michael Wu
2007-10-04 16:56     ` Michael Wu
2007-10-04 18:07 ` John W. Linville
2007-10-04 18:09 ` [PATCH] ieee80211_if_set_type: make check for master dev more explicit John W. Linville
2007-10-04 18:44   ` Johannes Berg
2007-10-04 19:13     ` John W. Linville
2007-10-04 19:13       ` John W. Linville
2007-10-05 12:01       ` Johannes Berg
2007-10-05 12:01         ` Johannes Berg
2007-10-04 21:26   ` Michael Wu
2007-10-04 21:26     ` Michael Wu
2007-10-04 23:02     ` John W. Linville
2007-10-04 23:02       ` John W. Linville
2007-10-06  2:23       ` Michael Wu
2007-10-06  2:23         ` Michael Wu

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=20071004181516.GH6037@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=dsd@gentoo.org \
    --cc=flamingice@sourmilk.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=netdev@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.