Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 6 Oct 2022 06:53:29 +0100
From:   Mauro Carvalho Chehab <mchehab@kernel.org>
To:     Jani Nikula <jani.nikula@linux.intel.com>
Cc:     Jonathan Corbet <corbet@lwn.net>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] docs: improve the HTML formatting of kerneldoc
 comments
Message-ID: <20221006065329.787c2592@sal.lan>
In-Reply-To: <87r0zmqkao.fsf@intel.com>
References: <20221004201222.281845-1-corbet@lwn.net>
        <20221004201222.281845-6-corbet@lwn.net>
        <87r0zmqkao.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Em Wed, 05 Oct 2022 19:58:39 +0300
Jani Nikula <jani.nikula@linux.intel.com> escreveu:

> On Tue, 04 Oct 2022, Jonathan Corbet <corbet@lwn.net> wrote:
> > Make a few changes to cause functions documented by kerneldoc to stand out
> > better in the rendered documentation.  Specifically, change kernel-doc to
> > put the description section into a ".. container::" section, then add a bit
> > of CSS to indent that section relative to the function prototype (or struct
> > or enum definition).  Tweak a few other CSS parameters while in the
> > neighborhood to improve the formatting.  
> 
> Way back I tried to keep the formatting changes minimal to avoid opening
> that particular can of worms along with the rest of the Sphinx
> transition.
> 
> But I do wonder if people find value in repeating e.g. the struct
> definitions in the documentation. I'd argue the rendered documentation
> is more for an overview, and if you need to know the exact details,
> you'll be in the editor typing code and you can look up the actual
> definition in source. Having the definition feels maybe a bit excessive.

I have split thoughts regards to it. The advantage of having the
struct definition there is to allow checking the type of each argument,
which is useful. It also provide a way to double-check if the parser
is dealing well with the argument, but, on the counter-side, the
type printed by kernel-doc may not be identical to what's inside the
Kernel, on some special cases, as the parse logic for arguments is
complex. The same applies on functions and macros.

> 
> We also don't use Sphinx C Domain's ".. c:member::" for struct/union
> members, 

I'm wondering how much extra build time this would impact ;-)
If the impact is not huge, I'm in favor of using it.

> or ".. c:enumerator::" for enumeration contants. 

This one can be more problematic, as it could break existing
cross-references.

> They provide arguably nicer rendering out of the box than our stuff.

Agreed.

> The Sphinx way to do parameter lists would be field lists i.e. ":param
> foo: description". Ditto for return values ":return: description". (Not
> saying we should convert the comments, but kernel-doc the script could
> emit those.)
> 
> Perhaps we'd be better off going towards Sphinx standard usage than
> tweaking our own thing?
> 
> I'm afraid I don't have the time to work on this. Talk is cheap and all
> that. My two cents.
> 
> Anyway, here are some examples how this might look like: [1].
> 
> 
> BR,
> Jani.
> 
> 
> 
> [1] https://hawkmoth.readthedocs.io/en/latest/examples.html

It reminds that we're currently lacking a  way to describe non-macro
#defines. In special for bit-based defines, it would be nice to have
a good way to document them, without needing to convert defines into 
enums.

Regards,
Mauro