All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [RFC] ath9k: fix tx queue selection
Date: Wed, 03 Nov 2010 10:04:08 -0700	[thread overview]
Message-ID: <4CD19608.4050901@candelatech.com> (raw)
In-Reply-To: <4CD19421.6000407@openwrt.org>

On 11/03/2010 09:56 AM, Felix Fietkau wrote:

>> Other than that I guess that it's basically an argument about
>> aesthetics, and you may very well be right. All I know is that I've
>> been following ath9k development now for almost two years and I'm
>> amazed by the severity of bugs that are still found, and I guess yet
>> to be found. We're dma:ing all over the place, deadlocking queues and
>> so on, on a regular basis, or at least we where 3 months ago. After
>> each one of these is fixed the attitude seems to be "now everything is
>> perfect and suggesting there could be some more problems or will be in
>> the future is just plain rude". Then yet another is found...
> I'm not saying we should assume that everything is always fine, but I do
> object to adding defensive code against made up scenarios of potential
> bugs that "might" be introduced at some point in the future.


I think a few WARN_ON_ONCE calls might be nice to have..folks
changing one part of the network stack often don't realize the subtle dependencies
in other parts..and a WARN_ON is a lot easier to debug than random
crashes and DMA errors.  For anyone reading the code, it is quite
obvious that you should never hit the WARN_ON, so I don't think it
adds any real clutter.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Felix Fietkau <nbd@openwrt.org>
Cc: "Björn Smedman" <bjorn.smedman@venatech.se>,
	ath9k-devel@venema.h4ckr.net,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] [RFC] ath9k: fix tx queue selection
Date: Wed, 03 Nov 2010 10:04:08 -0700	[thread overview]
Message-ID: <4CD19608.4050901@candelatech.com> (raw)
In-Reply-To: <4CD19421.6000407@openwrt.org>

On 11/03/2010 09:56 AM, Felix Fietkau wrote:

>> Other than that I guess that it's basically an argument about
>> aesthetics, and you may very well be right. All I know is that I've
>> been following ath9k development now for almost two years and I'm
>> amazed by the severity of bugs that are still found, and I guess yet
>> to be found. We're dma:ing all over the place, deadlocking queues and
>> so on, on a regular basis, or at least we where 3 months ago. After
>> each one of these is fixed the attitude seems to be "now everything is
>> perfect and suggesting there could be some more problems or will be in
>> the future is just plain rude". Then yet another is found...
> I'm not saying we should assume that everything is always fine, but I do
> object to adding defensive code against made up scenarios of potential
> bugs that "might" be introduced at some point in the future.


I think a few WARN_ON_ONCE calls might be nice to have..folks
changing one part of the network stack often don't realize the subtle dependencies
in other parts..and a WARN_ON is a lot easier to debug than random
crashes and DMA errors.  For anyone reading the code, it is quite
obvious that you should never hit the WARN_ON, so I don't think it
adds any real clutter.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2010-11-03 17:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 16:13 [ath9k-devel] [RFC] ath9k: fix tx queue selection Björn Smedman
2010-11-02 17:13 ` Felix Fietkau
2010-11-02 17:13   ` Felix Fietkau
2010-11-02 17:37   ` Felix Fietkau
2010-11-02 17:37     ` Felix Fietkau
2010-11-02 18:20     ` Björn Smedman
2010-11-02 18:20       ` Björn Smedman
2010-11-02 18:54       ` Felix Fietkau
2010-11-02 18:54         ` Felix Fietkau
2010-11-02 19:16         ` Björn Smedman
2010-11-02 19:16           ` Björn Smedman
2010-11-02 22:11           ` Felix Fietkau
2010-11-02 22:11             ` Felix Fietkau
2010-11-03 11:35             ` Björn Smedman
2010-11-03 11:35               ` Björn Smedman
2010-11-03 11:53               ` Felix Fietkau
2010-11-03 11:53                 ` Felix Fietkau
2010-11-03 16:27                 ` Björn Smedman
2010-11-03 16:27                   ` Björn Smedman
2010-11-03 16:56                   ` Felix Fietkau
2010-11-03 16:56                     ` Felix Fietkau
2010-11-03 17:04                     ` Ben Greear [this message]
2010-11-03 17:04                       ` Ben Greear
2010-11-03 17:31                     ` Björn Smedman
2010-11-03 17:31                       ` Björn Smedman
2010-11-03 17:48                       ` Felix Fietkau
2010-11-03 17:48                         ` Felix Fietkau
2010-11-02 18:12   ` Björn Smedman
2010-11-02 18:12     ` Björn Smedman
2010-11-02 22:59   ` Helmut Schaa
2010-11-02 22:59     ` Helmut Schaa

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=4CD19608.4050901@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath9k-devel@lists.ath9k.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.