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
> >
next prev parent 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 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.