All of lore.kernel.org
 help / color / mirror / Atom feed
From: mchehab@kernel.org (Mauro Carvalho Chehab)
To: cocci@systeme.lip6.fr
Subject: [Cocci] [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

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

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=cocci@systeme.lip6.fr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.