From: Jani Nikula <jani.nikula@intel.com>
To: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
Markus Heiser <markus.heiser@darmarit.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
linux-doc@vger.kernel.org
Subject: Re: RFC? [PATCH] docs-rst: kernel-doc: better output struct members
Date: Mon, 22 Aug 2016 14:16:23 +0300 [thread overview]
Message-ID: <874m6duk8o.fsf@intel.com> (raw)
In-Reply-To: <20160822070633.163af4b5@vento.lan>
On Mon, 22 Aug 2016, Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> Markus,
>
> Em Mon, 22 Aug 2016 10:56:01 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>
>> Am 21.08.2016 um 14:11 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>>
>> > Right now, for a struct, kernel-doc produces the following output:
>> >
>> > .. c:type:: struct v4l2_prio_state
>> >
>> > stores the priority states
>> >
>> > **Definition**
>> >
>> > ::
>> >
>> > struct v4l2_prio_state {
>> > atomic_t prios[4];
>> > };
>> >
>> > **Members**
>> >
>> > ``atomic_t prios[4]``
>> > array with elements to store the array priorities
>> >
>> > Putting a member name in verbatim and adding a continuation line
>> > causes the LaTeX output to generate something like:
>> > item[atomic_t prios\[4\]] array with elements to store the array priorities
>>
>>
>> Right now, the description of C-struct members is a simple rest-definition-list
>> (not in the c-domain). It might be better to use the c-domain for members:
>>
>> http://www.sphinx-doc.org/en/stable/domains.html#directive-c:member
>>
>> But this is not the only thing we have to consider. To make a valid C-struct
>> description (with targets/references in the c-domain) we need a more
>> *structured* reST markup where the members are described in the block-content
>> of the struct directive. E.g:
>>
>> <SNIP> -----------
>> |.. c:type:: struct v4l2_subdev_ir_ops
>> |
>> | operations for IR subdevices
>> |
>> | .. c:member:: int (* rx_read) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num)
>> |
>> <SNIP> -----------
>>
>> By this small example, you see, that we have to discuss the whole markup
>> produced by the kernel-doc script (function arguments, unions etc.).
>> IMHO, since kernel-doc is widely used, this should be a RFC.
>
> I tried using c:member. It won't work on LaTeX output, as it will
> still put everything into a LaTeX item, with doesn't do line breaks.
I've tried c:member before, and I'm not convinced it buys us anything
useful. I'm also not convinced we'd need more structured rst markup
within struct or function descriptions in addition to what we currently
have. Keep it simple.
BR,
Jani.
>
> Also, according to Sphinx manual at http://www.sphinx-doc.org/en/stable/domains.html
> The syntax is:
>
> .. c:member:: type name
>
> Describes a C struct member. Example signature:
>
> .. c:member:: PyObject* PyTypeObject.tp_bases
>
> So, it expects <type> <member> as arguments. If the manual is right, it
> would be expecting, instead, the weird syntax:
>
> .. c:member:: int (*) (struct v4l2_subdev *sd, u8 *buf, size_t count,ssize_t *num) rx_read
>
> With hurts my eyes.
>
> As I guess we don't want to maintain ourselves a LaTeX output Sphinx
> plugin forked from upstream, I guess that a more definitive solution
> would involve overriding the parser for c:member in a way that it would
> produce an output like the one in this path, while creating the proper
> c domain reference for the structure member inside the C domain.
>
> Regards,
> Mauro
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2016-08-22 11:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-21 12:11 [PATCH] docs-rst: kernel-doc: better output struct members Mauro Carvalho Chehab
2016-08-22 8:56 ` RFC? " Markus Heiser
2016-08-22 10:06 ` Mauro Carvalho Chehab
2016-08-22 11:16 ` Jani Nikula [this message]
2016-08-22 11:40 ` Markus Heiser
2016-08-22 11:52 ` Jani Nikula
2016-08-22 12:15 ` Mauro Carvalho Chehab
2016-08-22 12:23 ` Markus Heiser
2016-08-22 12:17 ` Markus Heiser
2016-08-22 11:42 ` Markus Heiser
2016-08-22 21:34 ` Jonathan Corbet
2016-08-23 0:40 ` 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=874m6duk8o.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@infradead.org \
--cc=mchehab@s-opensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.