From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755251AbcH1H4j (ORCPT ); Sun, 28 Aug 2016 03:56:39 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35118 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982AbcH1H4h (ORCPT ); Sun, 28 Aug 2016 03:56:37 -0400 Date: Sun, 28 Aug 2016 10:56:33 +0300 From: Alexey Dobriyan To: "Levin, Alexander" Cc: Joe Perches , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH , Sasha Levin , LKML Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ? Message-ID: <20160828075632.GA1852@p183.telecom.by> References: <1472330452.26978.23.camel@perches.com> <20160828005636.GB19088@sasha-lappy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160828005636.GB19088@sasha-lappy> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. I for one given up on it more or less since its introduction.