From: Carlos Bilbao <carlos.bilbao@amd.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
Matthew Wilcox <willy@infradead.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Avadhut Naik <Avadhut.Naik@amd.com>,
Miguel Ojeda <ojeda@kernel.org>,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [RFC] Proposal to relax warnings of htmldocs
Date: Wed, 16 Aug 2023 10:12:56 -0500 [thread overview]
Message-ID: <f7d0e554-b6ac-49ee-4caf-640967bc1053@amd.com> (raw)
In-Reply-To: <87bkf79row.fsf@intel.com>
On 8/16/23 06:01, Jani Nikula wrote:
> On Tue, 15 Aug 2023, Matthew Wilcox <willy@infradead.org> wrote:
>> On Tue, Aug 15, 2023 at 08:35:40PM +0200, Miguel Ojeda wrote:
>>> On Tue, Aug 15, 2023 at 8:23 PM Jonathan Corbet <corbet@lwn.net> wrote:
>>>>
>>>> As an alternative, of course, we could consider turning off those
>>>> specific warnings entirely for normal builds.
>>>
>>> It could be nice to get to enforce warning-free builds as soon as possible.
>>>
>>> Perhaps we could move those to a `W=1`-like group and clean them over
>>> time instead? Or do we have that already?
>>
>> I think the problem is that we don't run kernel-doc by default. Instead,
>> it's only run for W=1 (and higher) builds. That's why Carlos doesn't
>> see the problems he is introducing in his own builds. Of course, if
>> AMD required building with W=1 then they'd see these problems earlier
>> in their own testing. Apparently they don't.
>>
>> Is it time to just run kernel-doc by default? There aren't _that_
>> many kernel-doc warnings now. Not compared to how they used to be.
>> And enabling them for everyone means that new ones won't sneak in.
>> I haven't timed how much extra time kernel-doc adds to a build.
>> Perhaps that's infeasible.
>
> Personally, I believe it's easier to get at a warning free build (both
> compiler W=1 warnings as well as kernel-doc) by doing it driver and
> subsystem at a time, instead of, say, one warning at a time across the
> entire kernel. It's just too much of a burden to fix the entire kernel
> to enable a warning across the board.
>
> To that end, the i915 Makefile enables a lot more warnings than the
> defaults, and the developers and CI run the compiler and kernel-doc with
> -Werror. No new warnings get introduced.
>
> What I'd hope for is build system support to enable W=1
> compiler/kernel-doc warnings for a subdir with a few lines at most,
> instead of duplicating and copy-pasting tens of lines from
> scripts/Makefile.extrawarn like we have to do now.
That sounds feasible but, well, I actually proposed the opposite approach.
I wanted to "relax" the warnings (see RFC Subject) rather than making them
more strict by default.
My concern is that W=1 (by default) may theoretically result in a clean
`make htmldocs` but it won't in practice. Not all developers prioritize
good documentation like the folks from i915, and that may lead to
unaddressed warnings or worst, less interest in documenting the code. Isn't
it the case that some of these higher-control warnings don't really have
much effect in real life? And shoukd W=1 become the default, are we going
to be able to enforce that level of control?
If W=1 is decided to be the best approach I'm happy to help with that.
>
>
> BR,
> Jani.
>
>
Thanks,
Carlos
next prev parent reply other threads:[~2023-08-16 15:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 18:15 Carlos Bilbao
2023-08-15 18:23 ` Jonathan Corbet
2023-08-15 18:35 ` Miguel Ojeda
2023-08-15 18:41 ` Matthew Wilcox
2023-08-15 18:48 ` Carlos Bilbao
2023-08-16 11:01 ` Jani Nikula
2023-08-16 15:12 ` Carlos Bilbao [this message]
2023-08-16 15:15 ` Matthew Wilcox
2023-08-16 15:21 ` Carlos Bilbao
2023-08-16 15:57 ` Matthew Wilcox
2023-08-16 16:47 ` Carlos Bilbao
2023-08-16 14:54 ` Carlos Bilbao
2023-08-16 15:04 ` Jonathan Corbet
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=f7d0e554-b6ac-49ee-4caf-640967bc1053@amd.com \
--to=carlos.bilbao@amd.com \
--cc=Avadhut.Naik@amd.com \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=willy@infradead.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
all inboxes | Powered by JetHome®