From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
Nicolas Schier <nicolas.schier@linux.dev>
Cc: Akira Yokosawa <akiyks@gmail.com>,
Randy Dunlap <rdunlap@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] docs: kerneldoc.py: don't use Sphinx logger
Date: Tue, 20 May 2025 15:09:51 +0200 [thread overview]
Message-ID: <20250520150940.7d1cffec@sal.lan> (raw)
In-Reply-To: <20250520213906.6ec263d8@canb.auug.org.au>
Em Tue, 20 May 2025 21:39:06 +1000
Stephen Rothwell <sfr@canb.auug.org.au> escreveu:
> Hi Mauro,
>
> I do appreciate your work on the document system. Particularly you
> have made the process much faster. However, see below.
Hi Stephen,
> On Tue, 20 May 2025 11:19:56 +0200 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >
> > If by "innocent typo" you mean removing/renaming/moving a file from
> > the Kernel tree without updating Makefiles, or adding them with wrong
> > names, then yes: I do think this should be fatal for the affected "make"
> > targets. The quickest such build issues are caught, the best for everyone.
>
> They are found if you leave them as warnings and just continue on. I
> have been finding them by when the current python version just crashes
> (without any useful message before your current change) I rerun the
> htmldocs using the perl version to get the name of the missing file and
> then report it so it can be fixed. But the perl version continues on
> and produces all the other warnings so I can compare with the previous
> and only report new errors/warnigs. Sometime these reports are not
> foxed for days or weeks (or months).
>
The issues we're seeing weren't due to the conversion from perl to
python, but, instead, to the new logic that calls the Python methods
directly, instead of opening a shell to call kernel-doc.
Those caused some unintended changes, due to the way Sphinx works:
1. Sphinx has an overlay over the Python logger class. Such overlay
has some logic to output colored messages, which is interesting.
However, it also has a filtering logic which is affected by the
flags passed when sphinx-build is called. That was actually
suppressing not only verbose level logs, but also warnings and
errors. The fix is a single-line change:
- kfiles = KernelFiles(out_style=out_style, logger=logger)
+ kfiles = KernelFiles(out_style=out_style)
The patch is at:
https://lore.kernel.org/linux-doc/6b81b1aaa8446b4d850064dd38ffffa1a1cb6254.1747719873.git.mchehab+huawei@kernel.org/
2. Now that we're not opening a shell anymore, if kernel-doc.py
dies, it could cause a fatal error on Sphinx. I sent today
two patches fixing it:
2.1 Don't stop Documentation/sphinx/kerneldoc.py if a crash
happens:
https://lore.kernel.org/linux-doc/064bac2f462c13f56154891d8f3fb788db94f325.1747730982.git.mchehab+huawei@kernel.org/
2.2 Don't crash trying to retrieve kernel-doc messages from
a file that doesn't exist. This is patch 1/2 on this
series:
https://lore.kernel.org/lkml/d97e86c7176f671405b4c15d75cb951349022a23.1747730982.git.mchehab+huawei@kernel.org/
> So, please, now that you are producing more warnings, make a missing
> file just a warning (or at least continue on). I have enough to do
> every day without having to run "make htmldocs" more than once.
OK. As I said, the crash was unintended. The idea was to preserve
the old behavior as much as possible. Yet, it could probably be a
good idea to have a way in the future to control the docs behavior
for the cases where non-existing files are detected, allowing it to
stop quickly on such cases, instead of taking several minutes to
generate an html ouptut, as this could be useful for CI automation.
In order to simplify for Jon, I'll send those tree altogether(*).
(*) I'll add a 4th patch, adding scripts/lib/kdoc to linux-doc
content. Without that, Lore doesn't store kernel-doc changes as
part of docs. See:
https://lore.kernel.org/linux-doc/d97e86c7176f671405b4c15d75cb951349022a23.1747730982.git.mchehab+huawei@kernel.org/
Regards,
Mauro
prev parent reply other threads:[~2025-05-20 13:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 5:47 [PATCH 0/1] docs: kernel-doc: doesn't suppress error/warnings Mauro Carvalho Chehab
2025-05-20 5:47 ` [PATCH 1/1] docs: kerneldoc.py: don't use Sphinx logger Mauro Carvalho Chehab
2025-05-20 5:55 ` Randy Dunlap
2025-05-20 7:50 ` Mauro Carvalho Chehab
2025-05-20 8:23 ` Akira Yokosawa
2025-05-20 9:19 ` Mauro Carvalho Chehab
2025-05-20 11:39 ` Stephen Rothwell
2025-05-20 13:09 ` 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=20250520150940.7d1cffec@sal.lan \
--to=mchehab+huawei@kernel.org \
--cc=akiyks@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
/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