All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nicolas Schier <nsc@kernel.org>,
	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>
Subject: Re: [PATCH] kbuild: Do not run kernel-doc when building external modules
Date: Wed, 4 Feb 2026 12:12:47 +0100	[thread overview]
Message-ID: <20260204121247.0ee0eac4@localhost> (raw)
In-Reply-To: <dc38c823832997bc5f15dd9020e2e80c526f1b8a@intel.com>

On Wed, 04 Feb 2026 12:39:22 +0200
Jani Nikula <jani.nikula@linux.intel.com> wrote:

> 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"?

Agreed. Going further, maybe the best would be to define it per make
target, placing them on 3 groups:

- kbuild - make targets related to actually build the kernel;
- docs-build - make targets related to build docs;
- non-kbuild - the remaining random stuff over there.

To properly define what should be there, maybe the best would be to
look at "make help" and define what belongs to each group:


Cleaning targets:
- mostly kbuild (documentation is also part of cleaning targets)

Configuration targets:
- kbuild

Configuration topic targets:
- kbuild (I guess)

Other generic targets:
- kbuild: all, vmlinux, modules, modules_install, vdso_install, dir/*
- There is a grey area here with targets like cscope, gtags, tags/TAGS.
  I would consider those as non-kbuild.

Static analysers, Tools, Kernel selftest:
- I would also consider those as no-kbuild

Rust targets:
- dir/*: kbuild
- the other ones seem ancillary tooling. Probably, non-kbuild

Userspace tools targets:
- for sure no-kbuild

Kernel packaging:
- no-kbuild

Documentation targets:
- docs-build

Architecture-specific targets:
- kbuild

> 
> 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.

Agreed. Yet, better to document it somewhere.

> 
> > 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.

So true. on its current state, scripts/ is a place where people
ended adding random stuff over time.

-- 
Thanks,
Mauro

      reply	other threads:[~2026-02-04 11:12 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
2026-02-04 11:12           ` Mauro Carvalho Chehab [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=20260204121247.0ee0eac4@localhost \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=i@rong.moe \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@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 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.