From: Nicolas Schier <nsc@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Ethan Nelson-Moore <enelsonmoore@gmail.com>,
Shuah Khan <skhan@linuxfoundation.org>,
Chen Pei <cp0613@linux.alibaba.com>,
Randy Dunlap <rdunlap@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: kbuild: remove ISDN references in Makefile examples
Date: Thu, 18 Jun 2026 09:57:52 +0200 [thread overview]
Message-ID: <ajOlANn6mkCNiz-C@levanger> (raw)
In-Reply-To: <178175273131.3916864.13607634190318049114.b4-review@b4>
On Wed, Jun 17, 2026 at 08:18:51PM -0700, Nathan Chancellor wrote:
> On Sat, 13 Jun 2026 16:28:27 -0700, Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> > Documentation/kbuild/makefiles.rst uses some extracts from now-removed
> > ISDN code as examples. While they are harmless, they appeared in my
> > checks for CONFIG_* symbols referenced but not defined in the kernel.
> > Replace them with generic examples.
>
> While I am fine with adjusting these examples to make it easier on tools
> such as yours, how does this solve your problem? CONFIG_FOO and
> CONFIG_BAR are still not defined anywhere. Are you adding exceptions for
> these symbols? I ask because I would like these to be a little more
> "kernel specific" if that makes sense.
>
> Maybe it is not worth even checking Documentation/ for dead
> configurations at all since that is probably not going to be a bug very
> often but I guess it helps with cleaning up dead documentation?
>
> >
> >
> > diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
> > index 7521cae7d56f..ec8de1c20834 100644
> > --- a/Documentation/kbuild/makefiles.rst
> > +++ b/Documentation/kbuild/makefiles.rst
> > @@ -127,11 +127,8 @@ controllers are detected, and thus your disks are renumbered.
> >
> > Example::
> >
> > - #drivers/isdn/i4l/Makefile
> > - # Makefile for the kernel ISDN subsystem and device drivers.
> > - # Each configuration option enables a list of files.
>
> I think I would keep these comment, it is still relevant (at least to
> me).
>
> > - obj-$(CONFIG_ISDN_I4L) += isdn.o
> > - obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
> > + obj-$(CONFIG_FOO) += foo.o
> > + obj-$(CONFIG_BAR) += bar.o
>
> For instance, I think using a more descriptive symbol illustrates the
> example a little better.
>
> obj-$(CONFIG_DRIVER_ONE) += driver_one.o
> obj-$(CONFIG_DRIVER_TWO) += driver_two.o
>
> Same thing for the other examples. I just don't find these variable
> names to be particularly good when illustrating actual real world
> examples as opposed to conceptual ones. Not sure if others feel the same
> way.
+1
I liked that the examples were taken from actual Linux kconfigs, so it
was possible to look them up and check the context as well. So, yes, I
think updating these is a good idea!
Kind regards,
Nicolas
prev parent reply other threads:[~2026-06-18 7:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-13 23:28 [PATCH] docs: kbuild: remove ISDN references in Makefile examples Ethan Nelson-Moore
2026-06-14 15:00 ` Julian Braha
2026-06-14 21:54 ` Ethan Nelson-Moore
2026-06-18 3:18 ` Nathan Chancellor
2026-06-18 7:57 ` Nicolas Schier [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=ajOlANn6mkCNiz-C@levanger \
--to=nsc@kernel.org \
--cc=corbet@lwn.net \
--cc=cp0613@linux.alibaba.com \
--cc=enelsonmoore@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.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.