public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@fifo99.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jing Huang <huangj@brocade.com>,
	James.Bottomley@HansenPartnership.com, kgudipat@brocade.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	rvadivel@brocade.com, vravindr@brocade.com
Subject: Re: [PATCH 2/14] bfa: Brocade BFA FC SCSI driver (bfa1)
Date: Thu, 24 Sep 2009 09:15:35 -0700	[thread overview]
Message-ID: <1253808935.20648.211.camel@desktop> (raw)
In-Reply-To: <20090924165944.6507432a@lxorguk.ukuu.org.uk>

On Thu, 2009-09-24 at 16:59 +0100, Alan Cox wrote:
> > > +       return (*(union bfi_addr_u *) &addr);
> > > +}
> > 
> > Have you run checkpatch on this code? It produces many errors due to
> > your "return" usage for one.. The usual style of return is not to use
> > parentheses since it's really not a function ..
> 
> checkpatch is just a helper tool - and stuff like that using
> brackets to make it clearer is just a trivial matter of style.

True, but I do care about the style of code .. You may not care about it
which is fine ..

> > Checkpatch produces many other errors in your code .. If you haven't
> > already evaluated those errors
> 
> It would be rather more useful if instead of parroting checkpatch results
> (which people can generate themselves) you concentrated on analysis the
> actual code and structure for any flaws and design details.

They can generate them , but don't seem too .. For me, these problems
distract from the overall design .. I find it hard to focus on reviewing
larger topics like that when I know the trivial code clean ups have not
been done.. It's much easier to review clean code than code which has
lots of style problems.

> Trivia like coding style (unless particularly bad) are something for the
> maintainer just to say "fix those odd bits up and I'll merge it" at the
> *end*.

Well, isn't this the end for this patch set? He's asking for inclusion
in this thread, and it's been submitted once before already .. He has
also received enough comments for another round , so there isn't any
reason not to add the style clean ups, if any, to the next one.

Daniel


  reply	other threads:[~2009-09-24 16:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24  0:49 [PATCH 2/14] bfa: Brocade BFA FC SCSI driver (bfa1) Jing Huang
2009-09-24 15:44 ` Daniel Walker
2009-09-24 15:59   ` Alan Cox
2009-09-24 16:15     ` Daniel Walker [this message]
2009-09-24 17:38   ` Jing Huang
2009-09-24 17:55     ` Daniel Walker
2009-09-24 18:08       ` Jing Huang
2009-09-24 22:28         ` James Bottomley
2009-09-24 22:33           ` Jing Huang

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=1253808935.20648.211.camel@desktop \
    --to=dwalker@fifo99.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=huangj@brocade.com \
    --cc=kgudipat@brocade.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rvadivel@brocade.com \
    --cc=vravindr@brocade.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox