public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Nicolas Schier <nsc@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Rong Zhang <i@rong.moe>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Subject: Re: [PATCH] kbuild: Do not run kernel-doc when building external modules
Date: Wed, 04 Feb 2026 12:39:22 +0200	[thread overview]
Message-ID: <dc38c823832997bc5f15dd9020e2e80c526f1b8a@intel.com> (raw)
In-Reply-To: <aYMbVcNvJPlLPaaG@derry.ads.avm.de>

On Wed, 04 Feb 2026, Nicolas Schier <nsc@kernel.org> wrote:
> Well, sounds straight forward at first, but where should we make the
> cut between kbuild and non-kbuild?

I'll reply hypothetically, just for the sake of discussion, because
realistically, I don't think any of this is going to happen.

IMO the cut should be, "Is this required for configuring and building
the kernel"?

scripts/ just sounds like a dumping ground for random scripts, and
kbuild should be somewhere else. And let scripts/ be the dumping ground
that it is. If kbuild was under kbuild/, nobody in their right mind
would suggest adding random unrelated scripts there.

If kbuild depends on some things like objtool from somewhere else, so be
it, but at least don't pollute kbuild with unrelated things.

> I admit that there are some scripts below scripts/ that I'd rather
> label as "contrib", but I don't think that these are too much.

I've got to disagree there. I think there's so much that it's hard to
follow what is and isn't actually required for build.

At a *very* quick glance, there are things like checkpatch.pl,
get_maintainer.pl, anything coccinelle, bash-completion, Lindent,
macro_checker.py, bloat-o-meter, bootgraph.pl, etc, etc.

BR,
Jani.

-- 
Jani Nikula, Intel

  parent reply	other threads:[~2026-02-04 10:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30 21:37 [PATCH] kbuild: Do not run kernel-doc when building external modules Nathan Chancellor
2026-01-30 23:18 ` Randy Dunlap
2026-01-31 15:15 ` Nicolas Schier
2026-02-04  7:02   ` Masahiro Yamada
2026-02-04  7:39     ` Nathan Chancellor
2026-02-04 10:22       ` Mauro Carvalho Chehab
2026-02-04  9:10     ` Jani Nikula
2026-02-04 10:11       ` Nicolas Schier
2026-02-04 10:32         ` Mauro Carvalho Chehab
2026-02-04 10:39         ` Jani Nikula [this message]
2026-02-04 11:12           ` Mauro Carvalho Chehab

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=dc38c823832997bc5f15dd9020e2e80c526f1b8a@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=i@rong.moe \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=stable@vger.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