From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755372AbcH1J7n (ORCPT ); Sun, 28 Aug 2016 05:59:43 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:23500 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755321AbcH1J7l (ORCPT ); Sun, 28 Aug 2016 05:59:41 -0400 X-IronPort-AV: E=Sophos;i="5.28,590,1464645600"; d="scan'208";a="234300809" Date: Sun, 28 Aug 2016 11:59:38 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Alexey Dobriyan cc: "Levin, Alexander" , Joe Perches , Greg KH , Sasha Levin , "ksummit-discuss@lists.linuxfoundation.org" , LKML Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ? In-Reply-To: <20160828075632.GA1852@p183.telecom.by> Message-ID: References: <1472330452.26978.23.camel@perches.com> <20160828005636.GB19088@sasha-lappy> <20160828075632.GA1852@p183.telecom.by> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 28 Aug 2016, Alexey Dobriyan wrote: > On Sat, Aug 27, 2016 at 09:06:13PM -0400, Levin, Alexander via Ksummit-discuss wrote: > > 3. This one is somewhat subjective: scripts/checkpatch.pl is a massive blob of > > perl code that a fair amount of people don't know how to deal with. In 4.8 it's > > 6142 lines, making it the 124th largest source file in the kernel, well within > > the top 1% of source files in the kernel. > > > > This combination of size/language pushes people away from being involved in > > what is supposed to be a central tool and gives them a reason to never use > > it again after they see results they don't agree with (rather than fixing it). > > It is a textbook example of what's wrong with Perl. Instead of parsing > C code like compilers do, the script is one big pile of regexes. > It mostly works ("doing its job" in perlspeak) because people mostly > follow the coding style. Parsing is slow. Perfect parsing is impossible due to configuration options. There is definitely a place for regexps in checking code. Perhaps there is a better way to express the regexps, or to provide regexps for integration into the checkpatch infrastructure. > Regarding individual warnings: some are good (RETURN_VOID, DATE_TIME, > USE_NEGATIVE_ERRNO), some are OK given kernel style of allocating memory > but the rationale is bogus (UNNECESSARY_CASTS, linking to userspace > example of malloc() returning "int"!). > > And then there is ALLOC_SIZEOF_STRUCT which advocates "kmalloc(sizeof(*p))". > > The problem is that c-h.pl generates noise in the commit history and > makes git-blame less useful than it can be. Could it be that this is a problem with git blame, rather than with checkpatch? Last year there was a discussion on this list about how there is an option to git blame that will cause it to step through the history, and not show only the most recent patch that has modified a given line. julia > > I for one given up on it more or less since its introduction. > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss >