cocci.inria.fr archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Michal Marek <michal.lkml@markovi.net>,
	Gilles Muller <Gilles.Muller@lip6.fr>,
	linux-doc@vger.kernel.org, Nicolas Palix <nicolas.palix@imag.fr>,
	linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Coccinelle <cocci@systeme.lip6.fr>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [Cocci] [v3] documentation: coccinelle: Improve command example for make C={1, 2}
Date: Tue, 11 Aug 2020 10:24:08 +0200	[thread overview]
Message-ID: <20200811082408.GE113774@kroah.com> (raw)
In-Reply-To: <d6dcb49d-3dca-327e-e782-2cae789e31b7@web.de>

On Tue, Aug 11, 2020 at 09:03:09AM +0200, Markus Elfring wrote:
> >>> the usage of the makefile C variable flag by coccicheck.
> >>
> >> * Can it be confusing to denote an item as a variable and a flag?
> >>
> >> * Would you really like to stress here that a flag can be variable?
> >
> > This is not part of the documentation, so it doesn't really matter.
> 
> It seems then that your expectations for the clarity of change descriptions
> (or commit messages) can vary considerably.
> 
> 
> > Nevertheless, Sumera, there is stail an occurrence of flag in the proposed
> > change to the documentation, so you could indeed change that one to variable.
> 
> Will any related adjustments become more interesting?
> 
> 
> >>> +This variable can be used to run scripts for …
> >>
> >> Can the scope for a make command be selected also without such a variable?
> >
> > If you know something that is different than what is in the documentation,
> > then please say what it is.  Don't just ask questions.
> 
> I suggest to increase the distinction for the application of such command parameters.
> 
> 
> >> Will clarification requests for previously mentioned background information
> >> influence the proposed descriptions any further?
> >
> > The point is to document the use of make coccicheck,
> 
> Another attempt is evolving for the affected software documentation.
> 
> 
> > not the C variables.
> 
> I got an other impression here.
> 
> 
> > So the point about KBUILD_CHECK, while interesting, does not seem
> > appropriate for this documentation.
> 
> How do you think about to clarify the influence of a macro like “KBUILD_CHECKSRC”
> (or the specification “$(call cmd,force_checksrc)”)?
> 
> Will a cross reference for the applied make scripts help to achieve
> a better common understanding (and corresponding descriptions) of
> the involved dependencies?
> 
> Regards,
> Markus



Hi,

This is the friendly semi-automated patch-bot of Greg Kroah-Hartman.
You have sent him a patch that has triggered this response.

Right now, the development tree you have sent a patch for is "closed"
due to the timing of the merge window.  Don't worry, the patch(es) you
have sent are not lost, and will be looked at after the merge window is
over (after the -rc1 kernel is released by Linus).

So thank you for your patience and your patches will be reviewed at this
later time, you do not have to do anything further, this is just a short
note to let you know the patch status and so you don't worry they didn't
make it through.

thanks,

greg k-h's patch email bot
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

      parent reply	other threads:[~2020-08-11  8:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-10 20:16 [Cocci] [PATCH v3] documentation: coccinelle: Improve command example for make C={1, 2} Markus Elfring
2020-08-10 20:52 ` Julia Lawall
     [not found]   ` <d6dcb49d-3dca-327e-e782-2cae789e31b7@web.de>
2020-08-11  8:24     ` Greg Kroah-Hartman [this message]

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=20200811082408.GE113774@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Gilles.Muller@lip6.fr \
    --cc=Markus.Elfring@web.de \
    --cc=cocci@systeme.lip6.fr \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=michal.lkml@markovi.net \
    --cc=nicolas.palix@imag.fr \
    --cc=rdunlap@infradead.org \
    --cc=sam@ravnborg.org \
    --cc=willy@infradead.org \
    /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).