From: Liam Howlett <liam.howlett@oracle.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
Jani Nikula <jani.nikula@intel.com>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>,
"ksummit@lists.linux.dev" <ksummit@lists.linux.dev>,
Markus Heiser <markus.heiser@darmarit.de>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] What kernel documentation could be
Date: Mon, 27 Jun 2022 15:28:40 +0000 [thread overview]
Message-ID: <20220627152832.yigreu5ztnoxfp4g@revolver> (raw)
In-Reply-To: <20220626105306.122cdeda@sal.lan>
* Mauro Carvalho Chehab <mchehab@kernel.org> [220626 05:53]:
> Em Sun, 26 Jun 2022 08:55:24 +0100
> Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
>
> > Em Sat, 25 Jun 2022 11:11:40 -0700
> > Linus Torvalds <torvalds@linux-foundation.org> escreveu:
> >
> > > On Sat, Jun 25, 2022 at 7:00 AM Jonathan Corbet <corbet@lwn.net> wrote:
> > > >
> > > > I said "some" - this was a proof-of-concept hack. The complexity of
> > > > their symbol lookup code is ... daunting ... and not something that gets
> > > > fixed in one place. More research is required...
> > >
> > > Note that at least for me, the issue with building docs isn't hugely
> > > performance related.
> > >
> > > Yes, yes, it would be good if it was faster. But..
> > >
> > > The primary problems I see with building the docs (and thus checking
> > > them, the same way I do an allmodconfig build test) is
> > >
> > > (a) it's insanely noisy, which makes and "check that it's ok" ENTIRELY USELESS.
> >
> > When the environment is set for building docs, almost all output there
> > are actually due to build errors/warnings that got introduced by patches
> > touching documentation that were never build-tested.
> >
> > There are 4 components that report errors during "make htmldocs".
> >
> > 1. Documentation cross-reference check.
> ...
> > 2. ABI documentation check:
> ...
> > 3. kernel-doc warnings.
> ...
>
> Btw, once we fix the errors from the above checks, one of the things that
> could be done in order to avoid noisy doc builds would be to run this
> during normal Kernel build, if CONFIG_WERROR is set (and if .git is present
> at the source build dir):
>
> ./scripts/documentation-file-ref-check --warn
> ./scripts/get_abi.pl validate
> ./scripts/kernel-doc --none $(git grep kernel-doc $(git ls-files Documentation/|grep -v kernel-doc.rst)|perl -ne 'print "$1\n" if (m/kernel-doc::\s*(\S+)/);'|sort|uniq)
>
> aborting the build on such warnings.
>
> On my notebook (i5-10210U), the above takes ~8 seconds to run. So, it
> won't make much difference at the build time, and doing that would have
> avoided ~100 warnings during htmldocs build against current linux-next.
>
Couldn't we add this to the build bots and ask the authors to fix the
commits?
Thanks,
Liam
next prev parent reply other threads:[~2022-06-27 15:28 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 20:57 [TECH TOPIC] What kernel documentation could be Jonathan Corbet
2022-06-17 20:57 ` [Ksummit-discuss] " Jonathan Corbet
2022-06-17 21:48 ` Laurent Pinchart
2022-06-17 21:48 ` Laurent Pinchart
2022-06-27 15:18 ` Jonathan Corbet
2022-06-18 8:24 ` Mauro Carvalho Chehab
2022-06-18 8:24 ` Mauro Carvalho Chehab
2022-06-18 11:03 ` Miguel Ojeda
2022-06-18 11:16 ` Mauro Carvalho Chehab
2022-06-18 11:16 ` Mauro Carvalho Chehab
2022-06-18 14:37 ` Miguel Ojeda
2022-06-23 9:18 ` Jani Nikula
2022-06-23 9:57 ` Mauro Carvalho Chehab
2022-06-23 10:30 ` Jani Nikula
2022-06-23 13:40 ` Jonathan Corbet
2022-06-24 7:33 ` Mauro Carvalho Chehab
2022-06-24 16:37 ` Markus Heiser
2022-06-27 15:27 ` Jonathan Corbet
2022-06-27 15:31 ` Christoph Hellwig
2022-06-28 7:43 ` Mauro Carvalho Chehab
2022-06-28 7:57 ` Geert Uytterhoeven
2022-06-28 11:01 ` Mauro Carvalho Chehab
2022-07-02 12:43 ` Stephen Rothwell
2022-06-24 22:57 ` Jonathan Corbet
2022-06-25 9:10 ` Mauro Carvalho Chehab
2022-06-25 14:00 ` Jonathan Corbet
2022-06-25 18:11 ` Linus Torvalds
2022-06-26 7:55 ` Mauro Carvalho Chehab
2022-06-26 9:26 ` Mauro Carvalho Chehab
2022-06-26 9:53 ` Mauro Carvalho Chehab
2022-06-27 15:28 ` Liam Howlett [this message]
2022-06-27 15:54 ` Christian Brauner
2022-06-27 16:27 ` Mark Brown
2022-06-28 10:53 ` Mauro Carvalho Chehab
2022-06-28 16:13 ` Luck, Tony
2022-06-27 15:34 ` Jonathan Corbet
2022-06-27 17:07 ` Linus Torvalds
2022-07-02 10:52 ` Mauro Carvalho Chehab
2022-06-25 17:43 ` Steven Rostedt
2022-06-25 17:48 ` Laurent Pinchart
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=20220627152832.yigreu5ztnoxfp4g@revolver \
--to=liam.howlett@oracle.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).