From: Stephen Hemminger <shemminger@vyatta.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: "Németh Márton" <nm127@freemail.hu>,
"David Newall" <davidn@davidnewall.com>,
"Jeff Garzik" <jgarzik@pobox.com>,
netdev@vger.kernel.org,
"Trivial Patch Monkey" <trivial@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] 8139too: clean up spaces and TABs
Date: Mon, 16 Jun 2008 09:31:42 -0700 [thread overview]
Message-ID: <20080616093142.078f5528@extreme> (raw)
In-Reply-To: <485681BA.4060808@s5r6.in-berlin.de>
On Mon, 16 Jun 2008 17:07:38 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Németh Márton wrote:
> > I have chosen the checkpatch.pl's output to compare the
> > whether the old and the new code are better or not. Maybe that was a mistake.
>
> Well, running checkpatch on source files (rather than patches) and
> fixing the files up according to checkpatch's output and own good
> judgement has two uses:
> - bring new unmerged code into shape before submission,
> - bring older mainline code into the canonical form as a basis
> for further work. You certainly saw how lots and lots of such
> checkpatch-assisted cleanups went into arch/x86. That's because
> they were found useful for the work on unifying the two x86
> architecture subtrees.
> So, a coding style rework has its use even on legacy code if people have
> plans with the code. But keep in mind that (a) the whitespace rules
> aren't hard and universally agreed upon rules, (b) coding style has a
> number of other aspects of arguably greater importance than whitespace
> style, like proper modularization, good choices of names, use of common
> idioms and APIs instead of own inventions, and so on.
There is no point in doing this kind of checkpatch cleanup on its own.
It is worth doing more serious style work and rewriting of older drivers,
in the areas where other work needs to be done. Please work on drivers
that are ugly old vendor code, and/or you can find someone with the hardware
to test it.
next prev parent reply other threads:[~2008-06-16 16:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-14 12:36 [PATCH 1/2] 8139too: clean up spaces and TABs Németh Márton
2008-06-14 13:33 ` Stefan Richter
2008-06-14 18:43 ` Németh Márton
2008-06-14 19:53 ` Stefan Richter
2008-06-14 21:21 ` Ondrej Zary
2008-06-14 21:39 ` Francois Romieu
2008-06-15 7:50 ` Németh Márton
2008-06-15 7:52 ` [PATCH] 8139too: some style cleanups Németh Márton
2008-06-27 6:09 ` Jeff Garzik
2008-06-16 15:07 ` [PATCH 1/2] 8139too: clean up spaces and TABs Stefan Richter
2008-06-16 16:31 ` Stephen Hemminger [this message]
2008-06-15 6:21 ` David Newall
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=20080616093142.078f5528@extreme \
--to=shemminger@vyatta.com \
--cc=davidn@davidnewall.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nm127@freemail.hu \
--cc=stefanr@s5r6.in-berlin.de \
--cc=trivial@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.