[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070928093902.GA28455@elte.hu>
Date: Fri, 28 Sep 2007 11:39:02 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andy Whitcroft <apw@...dowen.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Randy Dunlap <rdunlap@...otime.net>,
Joel Schopp <jschopp@...tin.ibm.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.10
* Andy Whitcroft <apw@...dowen.org> wrote:
> > > WARNING: multiple assignments should be avoided
> > > #2319:
> > > + max_load = this_load = total_load = total_pwr = 0;
> >
> > That warning is non-bogus, although this is one of the bogosities
> > which I personally don't bother fixing or making a fuss about.
> >
> > But I do think it detracts from the readability of the code, and
> > from patches which later alter that code. A bit.
>
> I tend to agree, watching the automatic replies from checkpatch, the
> majority of these are "justifiable" in their context. I think I'll
> lower this one to a CHECK in the next release.
what matters is that only items should be displayed that i _can_ fix.
With v8 i was able to make kernel/sched*.c almost noise-free, but with
v9 and v10 that's not possible anymore. And the moment the default
output of the tool cannot be made 'empty', we've lost the biggest
battle. Seeing the same bogus (or borderline) warnings again and again
destroys the biggest dynamic that could get people to use this tool more
often: the gratification of having a 'perfectly clean' file/patch.
And this is not about any particular false positive. I dont mind an
"advanced mode" non-default opt-in option for the script, if someone is
interested in borderline or hard to judge warnings too, but these
default false positives are _lethal_ for a tool like this. (and i made
this point before.) This is a _fundamental_ thing, and i'm still not
sure whether you accept and understand that point. This is very basic
and very important, and this isnt the first (or second) time i raised
this.
Ingo
-
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