linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Knut Omang <knut.omang@oracle.com>
Cc: "Jani Nikula" <jani.nikula@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Nicolas Palix" <nicolas.palix@imag.fr>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"John Haxby" <john.haxby@oracle.com>,
	linux-doc@vger.kernel.org, "Jonathan Corbet" <corbet@lwn.net>,
	"Gilles Muller" <Gilles.Muller@lip6.fr>,
	"Michal Marek" <michal.lkml@markovi.net>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	"Julia Lawall" <Julia.Lawall@lip6.fr>,
	"Håkon Bugge" <haakon.bugge@oracle.com>,
	"Åsmund Østvold" <asmund.ostvold@oracle.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>,
	cocci@systeme.lip6.fr, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
Date: Sun, 7 Jan 2018 08:12:15 -0200	[thread overview]
Message-ID: <20180107081215.29a31ea5@vento.lan> (raw)
In-Reply-To: <1515181301.31439.724.camel@oracle.com>

Em Fri, 05 Jan 2018 20:41:41 +0100
Knut Omang <knut.omang@oracle.com> escreveu:

> On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 04 Jan 2018 21:15:31 +0100
> > Knut Omang <knut.omang@oracle.com> escreveu:
> >   
> > > > I'm surprised the commit message and the provided documentation say
> > > > nothing about using CHECK=foo on the command line. That already supports
> > > > arbitrary checkers.     
> > > 
> > > The problem, highlighted by Jim Davis in
> > > 
> > > https://lkml.org/lkml/2017/11/20/638
> > > 
> > > is that the current solution isn't flexible enough - that discussion 
> > > is what lead me to this reimplementation of what I originally intended 
> > > to be a checkpatch only solution.
> > >   
> > > > How does this relate to that? Is this supposed to be
> > > > a complete replacement? Or what?    
> > > 
> > > It has evolved into a complete replacement of the intention of CHECK.
> > >   
> > > > 'make help' also references $CHECK, and this patch doesn't update the
> > > > help text.    
> > > 
> > > I realize now that this needs to be handled in some way due to the way I split the 
> > > arguments with '--' - the intention was to keep it for bw compatibility.
> > > 
> > > It would be good to know if people rely on using CHECK with C={1,2} for 
> > > anything beside the checkers supported by runchecks today  
> > 
> > I do. Here, I use:
> > 
> > $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1
> > CHECK='compile_checks' M=drivers/media
> > 
> > Where "compile_checks" is actually a small script that calls both
> > smatch and sparse:
> > 
> > 	#!/bin/bash
> > 	/devel/smatch/smatch -p=kernel $@  
> 
> I suppose you here refer to this:
> https://blogs.oracle.com/linuxkernel/smatch-static-analysis-tool-overview,-by-dan-carpenter
> 
> Good idea! I'll have a look at how that plays with this.

Yes.

> 
> > 	/devel/sparse/sparse $@
> > 
> > So, I'm not sure why we need something else.   
> 
> The core functionality is the selective suppression logic and output unification
> which makes checking with automated build tools more flexible and 
> applicable right away (not when every warning from every checker is fixed...)

If the idea is to use it only/mostly with automated build tools, then
the better would be to call it only when explicitly requested, e. g.
something like C=3, in order to avoid breaking the usecase where one
would run its own script.

On my case, I use C=1 CHECK=compile_checks as part as my usual patch
handling. For every patch I apply on media, I call make again, to be
sure that no warning/building errors were added, not only with gcc
but also with smatch and sparse. 

> 
> > That said, I didn't look
> > on its code, but looking on its diffstat:
> > 
> >  Makefile                               |  23 +-
> >  scripts/Makefile.build                 |   4 +-
> >  scripts/runchecks                      | 734 ++++++++++++++++++++++++++-
> >  scripts/runchecks.cfg                  |  63 ++-
> >  scripts/runchecks_help.txt             |  43 ++-
> > 
> > Using a 734 lines python program just to do an exec on an external checker
> > seems too much!  
> 
> Sure, if that was the case I would be the first to agree :-)
> 
> Thanks,
> Knut
> 
> > Thanks,
> > Mauro  



Thanks,
Mauro

  reply	other threads:[~2018-01-07 10:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04 13:39 [PATCH v3 0/1] Support for generalized use of make C={1,2} via a wrapper program Knut Omang
2018-01-04 13:39 ` [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers Knut Omang
2018-01-04 15:50   ` Jani Nikula
2018-01-04 20:15     ` Knut Omang
2018-01-05 14:30       ` Jani Nikula
2018-01-05 16:05         ` Markus Heiser
2018-01-07 12:03         ` Philippe Ombredanne
2018-01-07 13:13           ` Knut Omang
2018-01-05 14:45       ` [v3] runchecks: Generalize make C={1, 2} " SF Markus Elfring
2018-01-05 18:08       ` [PATCH v3 1/1] runchecks: Generalize make C={1,2} " Mauro Carvalho Chehab
2018-01-05 19:41         ` Knut Omang
2018-01-07 10:12           ` Mauro Carvalho Chehab [this message]
2018-01-08  7:33             ` Knut Omang

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=20180107081215.29a31ea5@vento.lan \
    --to=mchehab@kernel.org \
    --cc=Gilles.Muller@lip6.fr \
    --cc=Julia.Lawall@lip6.fr \
    --cc=alexander.levin@verizon.com \
    --cc=asmund.ostvold@oracle.com \
    --cc=cocci@systeme.lip6.fr \
    --cc=corbet@lwn.net \
    --cc=haakon.bugge@oracle.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=john.haxby@oracle.com \
    --cc=knut.omang@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=michal.lkml@markovi.net \
    --cc=nicolas.palix@imag.fr \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=willy@infradead.org \
    --cc=yamada.masahiro@socionext.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).