public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Nicolas Schier <nicolas.schier@linux.dev>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	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 11:19:56 +0200	[thread overview]
Message-ID: <20250520111956.1db9db88@sal.lan> (raw)
In-Reply-To: <590981da-4d37-464f-a52e-ba163d3ecbc5@gmail.com>

Em Tue, 20 May 2025 17:23:30 +0900
Akira Yokosawa <akiyks@gmail.com> escreveu:

> On Tue, 20 May 2025 09:50:37 +0200, Mauro Carvalho Chehab wrote:
> > Hi Randy,
> > 
> > Em Mon, 19 May 2025 22:55:08 -0700
> > Randy Dunlap <rdunlap@infradead.org> escreveu:
> >   
> [...]
> 
> >> Traceback
> >> =========
> >>
> >>       File "/usr/lib/python3.13/site-packages/sphinx/util/parallel.py", line 137, in _join_one
> >>         raise SphinxParallelError(*result)
> >>     sphinx.errors.SphinxParallelError: KeyError: '../drivers/gpio/gpiolib-acpi.c'
> >>
> >> and then it's finished (not a normal finish).
> >> So IMHO this patch is not sufficient.  
> > 
> > Well, on next-20250516:
> > 
> > 	$ ls drivers/gpio/gpiolib-acpi.c
> > 	ls: cannot access 'drivers/gpio/gpiolib-acpi.c': No such file or directory
> > 
> > Avoiding the script to abort is a matter of adding a try/except
> > block at kerneldoc.py, but I'd say that, if an include file (or any other
> > file needed for the build) is not found, "make" should abort anyway for
> > the affected target (Kernel compilation or when doc building).  
> 
> Interesting ...
> 
> So, it sounds to me you think you have the right to break Stephen's (and
> possibly other devs') workflow of test-building kernel docs, aren't you?
> 
> I don't buy such an argument.
> 
> An innocent typo in pathname somewhere in the doc tree deserves a friendly
> warning at most, not a fatal crash within Sphinx.  That would need another
> run of "make htmldocs" after fixing the fatal error to see for other
> innocuous warnings.

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.

Yet, this is is a separate discussion: if there are bugs at the doc
build system, they should be fixed. In this specific case, the missing
file produces a KeyError when the messages that were supposed to be
generated by it aren't stored on a dict. I sent already some patches
addressing it:

	https://lore.kernel.org/linux-doc/cover.1747730982.git.mchehab+huawei@kernel.org/T/#t

Plus the logger fix to prevent Sphinx to suppress warnings/errors:
	https://lore.kernel.org/linux-doc/cover.1747719873.git.mchehab+huawei@kernel.org/T/#t

> 
> And your change has no effect on exposing those innocuous warnings.
> 
> On current docs-next + your change above, running:
> 
>     make cleandocs; make KERNELDOC=$PWD/scripts/kernel-doc.pl htmldocs
> 
> produces these 3 warnings:
> 
> ----------------------------------------------------------------------
> ./drivers/gpu/drm/amd/include/amd_shared.h:369: warning: Incorrect use of kernel-doc format:          * @DC_HDCP_LC_ENABLE_SW_FALLBACK If set, upon HDCP Locality Check FW
> ./drivers/gpu/drm/amd/include/amd_shared.h:369: warning: Incorrect use of kernel-doc format:          * @DC_HDCP_LC_ENABLE_SW_FALLBACK If set, upon HDCP Locality Check FW
> ./drivers/gpu/drm/amd/include/amd_shared.h:373: warning: Enum value 'DC_HDCP_LC_ENABLE_SW_FALLBACK' not described in enum 'DC_DEBUG_MASK'
> ----------------------------------------------------------------------
> 
> , while running:
> 
>     make cleandocs; make htmldocs
> 
> or:
> 
>     make cleandocs; make KERNELDOC=$PWD/scripts/kerneldoc htmldocs
> 
> doesn't produce them.

Testing here with next-20250516:

	$ ./scripts/kernel-doc.pl -Wall -none ./drivers/gpu/drm/amd/include/amd_shared.h
	$

	$ ./scripts/kernel-doc.py -Wall -none ./drivers/gpu/drm/amd/include/amd_shared.h
	$

Also, if I rename the value 'DC_HDCP_LC_ENABLE_SW_FALLBACK_XXX',
both produces identical warnings:

	$ ./scripts/kernel-doc.pl -Wall -none ./drivers/gpu/drm/amd/include/amd_shared.h
	./drivers/gpu/drm/amd/include/amd_shared.h:373: warning: Enum value 'DC_HDCP_LC_ENABLE_SW_FALLBACK_XXX' not described in enum 'DC_DEBUG_MASK'
	./drivers/gpu/drm/amd/include/amd_shared.h:373: warning: Excess enum value 'DC_HDCP_LC_ENABLE_SW_FALLBACK' description in 'DC_DEBUG_MASK'

	$ ./scripts/kernel-doc.py -Wall -none ./drivers/gpu/drm/amd/include/amd_shared.h
	Warning: ./drivers/gpu/drm/amd/include/amd_shared.h:372 Enum value 'DC_HDCP_LC_ENABLE_SW_FALLBACK_XXX' not described in enum 'DC_DEBUG_MASK'
	Warning: ./drivers/gpu/drm/amd/include/amd_shared.h:372 Excess enum value '%DC_HDCP_LC_ENABLE_SW_FALLBACK' description in 'DC_DEBUG_MASK'

So, it sounds to me that things are the way they're expected,
after applying both series.

Regards,
Mauro

  reply	other threads:[~2025-05-20  9:20 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 [this message]
2025-05-20 11:39           ` Stephen Rothwell
2025-05-20 13:09             ` 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=20250520111956.1db9db88@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