public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Rob Herring <robh@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Whitcroft <apw@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] checkpatch.pl: Add SPDX license tag check
Date: Thu, 09 Nov 2017 10:27:40 -0800	[thread overview]
Message-ID: <1510252060.15768.66.camel@perches.com> (raw)
In-Reply-To: <CAL_JsqJrLxkrpJcXj4GGXj-xjf_1kE1EKn1+yWMD6knvk1AB6w@mail.gmail.com>

On Thu, 2017-11-09 at 12:12 -0600, Rob Herring wrote:
> On Thu, Nov 9, 2017 at 9:39 AM, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2017-11-09 at 07:47 -0600, Rob Herring wrote:
> > > On Wed, Nov 8, 2017 at 8:10 PM, Joe Perches <joe@perches.com> wrote:
> > > > On Wed, 2017-11-08 at 19:10 -0600, Rob Herring wrote:
> > > > > Add a check warning if SPDX-License-Identifier tags are not used in
> > > > > newly added files.
> > > > 
> > > > If this is to be done, and I think it's not a great idea,
> > > 
> > > Which part? SPDX tags or checking new files or just using checkpatch for this?
> > 
> > SPDX tags in all files.

Is having an SPDX tag in every file really desired?

> > 
> > There's no real way to check a patch for this.
> > 
> > You have to check the entire file.
> 
> Changing existing files is a separate problem. There is a script for
> that (though the data file is not public). I'm only worried with new
> files here because that's what I review and have to tell folks to
> replace their 2 pages of license text with SPDX tags. (It will be much
> easier to just tell them to run checkpatch. ;) ).
> 
> > checkpatch could, as you've done, scan for new files
> > against /dev/null, but a single patch can add
> > multiple files and each newly added file should have
> > a missing SPDX indicator check.
> 
> I was going with the easy route of just giving one warning per patch.
> I'd hope that's enough info for folks to figure out what's needed from
> there. However, it should be possible to make it per file. The main
> complication is we need to look for either '^+++' or the end of the
> patch which I didn't see an easy/clean way to do.

EOF is easy.
There already is a $realfile test for start of file.

> > My concern is that there are ~50,000 files in the
> > kernel source tree and, after that scripted patch
> > adding the tags, only about a quarter of them have
> > an SPDX tag.
> > 
> > So which files actually _need_ a SPDX tag?
> > 
> > files in -next with an SPDX tag:
> > 
> > $ git grep --name-only -i -P "spdx-licen[cs]e-identifier" | \
> >   while read file ; do basename $file ; done | \
> >   sed -r -e 's/^.*(\..*)/\1/' | \
> >   sort | uniq -c | sort -rn | head -10
> >    7514 .h
> >    3435 .c
> >    1193 Makefile
> >     486 .S
> >     221 .dts
> >     186 Kconfig
> >     185 .dtsi
> >      97 .sh
> >      34 .tc
> >      24 .debug
> > 
> > vs all files in -next (not Documentation/)
> > 
> > $ git ls-files | grep -v "^Documentation/" | \
> >   while read file ; do basename $file ; done | \
> >   sed -r -e 's/^.*(\..*)/\1/' | \
> >   sort | uniq -c | sort -rn | head -10
> >   25946 .c
> >   20360 .h
> >    2437 Makefile
> >    1454 .S
> >    1442 .dts
> >    1380 Kconfig
> >    1099 .dtsi
> >     207 .json
> >     204 .gitignore
> >     194 .sh
> > 

  reply	other threads:[~2017-11-09 18:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  1:10 [PATCH] checkpatch.pl: Add SPDX license tag check Rob Herring
2017-11-09  2:10 ` Joe Perches
2017-11-09  9:12   ` Greg Kroah-Hartman
2017-11-09 13:55     ` Joe Perches
2017-11-09 13:47   ` Rob Herring
2017-11-09 15:39     ` Joe Perches
2017-11-09 18:12       ` Rob Herring
2017-11-09 18:27         ` Joe Perches [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-02-01 21:14 Rob Herring
2018-02-01 21:49 ` Joe Perches
2018-02-02  7:56 ` Greg Kroah-Hartman
2018-02-08 14:23 ` Philippe Ombredanne

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=1510252060.15768.66.camel@perches.com \
    --to=joe@perches.com \
    --cc=apw@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.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