All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Mitch Williams <mitch.a.williams@intel.com>
Cc: "Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
	Matt Mackall <mpm@selenic.com>,
	"Garzik, Jeff" <jgarzik@pobox.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	Jeff Moyer <jmoyer@redhat.com>,
	netdev@vger.kernel.org, "Brandeburg,
	Jesse" <jesse.brandeburg@intel.com>,
	"Kok, Auke" <auke@foo-projects.org>
Subject: Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Date: Thu, 8 Jun 2006 14:39:03 -0400	[thread overview]
Message-ID: <20060608183857.GA16733@tuxdriver.com> (raw)
In-Reply-To: <1149787436.2928.9.camel@strongmad>

On Thu, Jun 08, 2006 at 10:23:56AM -0700, Mitch Williams wrote:
> On Wed, 2006-06-07 at 11:54 -0700, John W. Linville wrote:
> 
> > Pedantic objection, but I think this would read easier w/o the extra
> > newline before disable_irq.
> 
> Heh.  I prefer to have a newline between declarations and code.  The

Normally I would agree.  But in this case, I find the distraction of
the random newline after the #else to be more compelling.

> real problem is the position of the #ifdef -- that's what makes it
> difficult to read.  The other solution would be
> {
>         struct e1000_adapter *adapter = netdev_priv(netdev);
> #ifdef CONFIG_E1000_NAPI
> 	int budget = 0;
> #endif
> 
> 	disable_irq(adapter->pdev->irq);
> 
> #ifdef CONFIG_E1000_NAPI
> 	< all that stuff >
> #else
> 	<rest of the stuff >
> #endif
> }
> 
> Which I think is worse to read.

I presume it is the double #ifdef that you find objectionable?
I don't really like it, but at least that idiom is quite common.

Given that the disable_irq appears in both code paths (almost by
necessity), there is a certain appeal to having it outside of the
#ifdef block.  That seems more maintainable.

To me, the idiomatic #ifdef placement seems more readable, if for no
other reason than familiarity.  I suppose we can agree to disagree.

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

  reply	other threads:[~2006-06-08 18:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-05 23:09 [PATCH 0/2] e1000: fixes for netpoll+NAPI, ARM Kok, Auke
2006-06-05 23:11 ` [PATCH 1/2] e1000: fix netpoll with NAPI Kok, Auke
2006-06-06 13:52   ` Neil Horman
2006-06-06 16:39     ` Mitch Williams
2006-06-06 17:05       ` Neil Horman
2006-06-06 17:18         ` Auke Kok
2006-06-06 17:30           ` Jeff Moyer
2006-06-06 17:34             ` Auke Kok
2006-06-06 17:42               ` Jeff Moyer
2006-06-06 23:17                 ` Matt Mackall
2006-06-07 15:05                   ` Neil Horman
2006-06-07 16:48                     ` Matt Mackall
2006-06-07 18:25                       ` Auke Kok
2006-06-07 18:44                         ` Jeff Moyer
2006-06-07 19:18                           ` Neil Horman
2006-06-08 17:19                           ` Mitch Williams
2006-06-08 17:29                             ` Jeff Moyer
2006-06-12  0:13                               ` Neil Horman
2006-06-12 16:42                                 ` Mitch Williams
2006-06-12 18:06                                   ` Neil Horman
2006-06-14 20:41                                     ` Neil Horman
2006-06-14 23:44                                       ` Mitch Williams
2006-06-15 12:44                                         ` John W. Linville
2006-06-15 20:45                                           ` Mitch Williams
2006-06-20  8:28                                             ` Andrew Grover
2006-06-07 18:54                         ` John W. Linville
2006-06-08 17:23                           ` Mitch Williams
2006-06-08 18:39                             ` John W. Linville [this message]
2006-06-06 17:29       ` Jeff Moyer
2006-06-05 23:11 ` [PATCH 2/2] e1000: remove risky prefetch on next_skb->data Kok, Auke
2006-06-05 23:21   ` Rick Jones
2006-06-06  0:12     ` Brandeburg, Jesse
2006-06-06  0:16       ` Rick Jones
2006-06-06  0:22         ` Andi Kleen
2006-06-06  0:26         ` Brandeburg, Jesse

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=20060608183857.GA16733@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=auke-jan.h.kok@intel.com \
    --cc=auke@foo-projects.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=jmoyer@redhat.com \
    --cc=mitch.a.williams@intel.com \
    --cc=mpm@selenic.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    /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.