[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1254927438.18167.275.camel@desktop>
Date: Wed, 07 Oct 2009 07:57:17 -0700
From: Daniel Walker <dwalker@...o99.com>
To: Krzysztof Halasa <khc@...waw.pl>
Cc: Andy Whitcroft <apw@...onical.com>, Li Zefan <lizf@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 3/5] checkpatch: add a blacklist
On Wed, 2009-10-07 at 16:44 +0200, Krzysztof Halasa wrote:
> Daniel Walker <dwalker@...o99.com> writes:
>
> >>From my perspective Documentation/SubmittingPatches really dictates what
> > you should be doing with checkpatch, since that was signed off on by
> > Andy (on this thread) and Linus .. In that document I think checkpatch
> > is given authority, rather than what your suggesting where it's just
> > something you can use or not, and ignore or not like it has no meaning
> > at all..
>
> Checkpatch is a tool. How a tool can have authority? Code authors can
> have authority. Maintainers can have authority. Linus as the "top"
> maintainer can have authority. But a tool?
>
> If checkpatch had any authority, the file in question (ext4.h) would
> have to be "fixed" without questions and exceptions.
>
> I don't say its warnings and errors have no meaning at all. It may be
> very helpful at times, but still it's only a tool.
Right it's a tool .. However, you should use it and you should follow
it. If for some reason you disagree with the tool you have to give at
least an arguable reason why, not just "It's a guide", "I don't like the
coding style." etc..
In the case of Steven's code he has an arguable reason why he's not
following checkpatch..
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists