From: Jani Nikula <jani.nikula@linux.intel.com>
To: Masahiro Yamada <masahiroy@kernel.org>, Nicolas Schier <nsc@kernel.org>
Cc: 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 11:10:37 +0200 [thread overview]
Message-ID: <6387ba7b99fb952a59932c3a851dfd0ecc4dfb2c@intel.com> (raw)
In-Reply-To: <CAK7LNARR9bZQ9t9emcVzmL+P7xYemu=8s8v_LshQ0-m_zEE9mA@mail.gmail.com>
On Wed, 04 Feb 2026, Masahiro Yamada <masahiroy@kernel.org> wrote:
> Since kernel-doc is a part of Kbuild,
> all dependent libraries should exist under scripts/.
Huh. I've always wondered why all the Kbuild makefiles are placed in
scripts/, which appears to be a haphazard collection of, well, scripts
and tools. But then you also have tools/.
I've followed the kernel-doc refactoring from the sidelines, commenting
on some things, but it never crossed my mind the build shouldn't depend
on something outside of scripts/. (That's what I'm inferring here
anyway.) And apparently that thought didn't occur to a lot of other
people either, with even more kernel experience than myself.
Sounds like the kernel config and build system would deserve a top-level
directory like build/ or kbuild/, which collects everything needed for
the build, nothing more, nothing less. Because scripts/ is not *that*.
I understand all of this may be a historical accident, and possibly too
painful to fix now, but is any of this documented anywhere either?
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-02-04 9:10 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 [this message]
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
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=6387ba7b99fb952a59932c3a851dfd0ecc4dfb2c@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 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.