All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Nicolas Schier <nsc@kernel.org>,
	Andrew Jones <andrew.jones@linux.dev>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kconfig: add kconfig-sym-check static checker
Date: Sun, 17 May 2026 18:11:28 +0900	[thread overview]
Message-ID: <20260517091128.GA3773662@ax162> (raw)
In-Reply-To: <aglc1wxyLtEWX2qW@ashevche-desk.local>

On Sun, May 17, 2026 at 09:14:47AM +0300, Andy Shevchenko wrote:
> On Sun, May 17, 2026 at 01:26:07PM +0900, Nathan Chancellor wrote:
> > On Fri, May 15, 2026 at 09:08:07PM +0200, Nicolas Schier wrote:
> > > On Thu, May 14, 2026 at 10:32:12PM +0900, Nathan Chancellor wrote:
> > > > On Wed, 13 May 2026 16:03:29 -0500, Andrew Jones <andrew.jones@linux.dev> wrote:
> 
> [...]
> 
> > > > > diff --git a/scripts/kconfig/kconfig-sym-check.pl b/scripts/kconfig/kconfig-sym-check.pl
> > > > > new file mode 100755
> > > > > index 000000000000..a6907e585962
> > > > > --- /dev/null
> > > > > +++ b/scripts/kconfig/kconfig-sym-check.pl
> > > > > @@ -0,0 +1,93 @@
> > > > > +#!/usr/bin/env perl
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +
> > > > > +use warnings;
> > > > > +use strict;
> > > > > +
> > > > > +my $kconfig_sym_check_excludes = undef;
> > > > > +$kconfig_sym_check_excludes = $ARGV[0] if (defined $ARGV[0]);
> > > > > +
> > > > > +my @files = `git ls-files '*Kconfig*'`;
> > > > 
> > > > What happens if you run this command on a release tarball? We should
> > > > probably use something like
> > > > 
> > > >   find $(srctree) -name '*Kconfig*'
> > > 
> > > not fully related, but that reminds me to this thread:
> > > https://lore.kernel.org/linux-kbuild/CAK7LNATJ-3JQ0QQGQ5R+R8aBJEq-tmBL8iBZrbM_4t0zeoYTaw@mail.gmail.com/#r
> > 
> > Ah yeah, that is definitely worth keeping in mind for the future. I feel
> > like 'find' is not "more complicated" than 'git ls-files' in this case,
> > so I will assume that such an objection would not really hold here
> > (especially since it would help people with development of fresh Kconfig
> > files that have not been committed yet). If we did want to rely on 'git
> > ls-files', we should at least error gracefully if we are not in a git
> > checkout.
> 
> Can we do both depending on the environment (if we are in Git, do that,
> otherwise fallback to `find`)? `find` uses FS, while Git uses index, which
> is much faster.

It feels like that starts to get into the complicated territory for
little gain, considering there is indeed a performance difference but I
am not sure that it is an obvious one in the grand scheme of things.

  $ hyperfine 'git ls-files "*Kconfig*"' 'find . -name "*Kconfig*"'
  Benchmark 1: git ls-files "*Kconfig*"
    Time (mean ± σ):      24.6 ms ±   1.0 ms    [User: 18.0 ms, System: 6.1 ms]
    Range (min … max):    20.5 ms …  28.7 ms    120 runs

  Benchmark 2: find . -name "*Kconfig*"
    Time (mean ± σ):     222.9 ms ±   4.5 ms    [User: 80.6 ms, System: 140.1 ms]
    Range (min … max):   216.0 ms … 227.6 ms    13 runs

  Summary
    git ls-files "*Kconfig*" ran
      9.06 ± 0.43 times faster than find . -name "*Kconfig*"

But I don't know how complicated such checking is in Perl, so I would be
willing to see what it looks like.

-- 
Cheers,
Nathan

  reply	other threads:[~2026-05-17  9:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 21:03 [PATCH] kconfig: add kconfig-sym-check static checker Andrew Jones
2026-05-13 21:44 ` Andy Shevchenko
2026-05-13 23:31 ` Randy Dunlap
2026-05-14 13:32 ` Nathan Chancellor
2026-05-14 13:51   ` Andrew Jones
2026-05-14 15:26   ` Julian Braha
2026-05-14 16:01     ` Nathan Chancellor
2026-05-15 19:08   ` Nicolas Schier
2026-05-17  4:26     ` Nathan Chancellor
2026-05-17  6:14       ` Andy Shevchenko
2026-05-17  9:11         ` Nathan Chancellor [this message]
2026-05-17  9:58           ` Andy Shevchenko
2026-05-17 21:50             ` Nathan Chancellor

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=20260517091128.GA3773662@ax162 \
    --to=nathan@kernel.org \
    --cc=andrew.jones@linux.dev \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nsc@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.