All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	george.dunlap@citrix.com, ian.jackson@eu.citrix.com,
	julien@xen.org, wl@xen.org,
	Stefano Stabellini <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH 05/14] kernel-doc: public/features.h
Date: Mon, 17 Aug 2020 17:26:32 +0200	[thread overview]
Message-ID: <8b8a63fb-5b79-42ba-7d6f-d1538775033a@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2008071239130.16004@sstabellini-ThinkPad-T480s>

On 07.08.2020 23:52, Stefano Stabellini wrote:
> On Fri, 7 Aug 2020, Jan Beulich wrote:
>> On 07.08.2020 01:49, Stefano Stabellini wrote:
>>> @@ -41,19 +41,25 @@
>>>   * XENFEAT_dom0 MUST be set if the guest is to be booted as dom0,
>>>   */
>>>  
>>> -/*
>>> - * If set, the guest does not need to write-protect its pagetables, and can
>>> - * update them via direct writes.
>>> +/**
>>> + * DOC: XENFEAT_writable_page_tables
>>> + *
>>> + * If set, the guest does not need to write-protect its pagetables, and
>>> + * can update them via direct writes.
>>>   */
>>>  #define XENFEAT_writable_page_tables       0
>>
>> I dislike such redundancy (and it's more noticable here than with
>> the struct-s). Is there really no way for the tool to find the
>> right item, the more that in the cover letter you say that you
>> even need to get the placement right, i.e. there can't be e.g.
>> intervening #define-s?
> 
> Let me clarify that the right placement (nothing between the comment and
> the following structure) is important for structs, typedefs, etc., but
> not for "DOC". DOC is freeform and doesn't have to be followed by
> anything specifically.
> 
> 
> In regards to the redundancy, there is only another option, that I
> didn't choose because it leads to worse documents being generated.
> However, they are still readable, so if the agreement is to use the
> other format, I would be OK with it.
> 
> 
> The other format is the keyword "macro" (this one would have to have the
> right placement, straight on top of the #define):
> 
> /**
>  * macro XENFEAT_writable_page_tables
>  *
>  * If set, the guest does not need to write-protect its pagetables, and
>  * can update them via direct writes.
>  */
> 
> 
> Which could be further simplified to:
> 
> /**
>  * macro
>  *
>  * If set, the guest does not need to write-protect its pagetables, and
>  * can update them via direct writes.
>  */
> 
> 
> In terms of redundancy, that's the best we can do.
> 
> The reason why I say it is not optimal is that with DOC the pleudo-html
> generated via sphinx is:
> 
> ---
> * XENFEAT_writable_page_tables *
> 
> If set, the guest does not need to write-protect its pagetables, and
> can update them via direct writes.
> ---
> 
> While with macro, two () parenthesis gets added to the title, and also an
> empty "Parameters" section gets added, like this:
> 
> ---
> * XENFEAT_writable_page_tables() *
> 
> ** Parameters **
> 
> ** Description **
> 
> If set, the guest does not need to write-protect its pagetables, and
> can update them via direct writes.
> ---
> 
> 
> I think it could be confusing to the user: it looks like a macro with
> parameters, which is not what we want.

Agreed, so ...

> For that reason, I think we should stick with "DOC" for now.

... if there are no (better) alternatives we'll have to live with the
redundancy.

Jan


  reply	other threads:[~2020-08-17 15:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-06 23:49 [PATCH 00/14] kernel-doc: public/arch-arm.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 01/14] " Stefano Stabellini
2020-08-18 12:42   ` Ian Jackson
2020-08-20 19:05     ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 02/14] kernel-doc: public/hvm/hvm_op.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 03/14] kernel-doc: public/device_tree_defs.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 04/14] kernel-doc: public/event_channel.h Stefano Stabellini
2020-08-07 13:01   ` Jan Beulich
2020-08-07 21:51     ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 05/14] kernel-doc: public/features.h Stefano Stabellini
2020-08-07 12:54   ` Jan Beulich
2020-08-07 21:52     ` Stefano Stabellini
2020-08-17 15:26       ` Jan Beulich [this message]
2020-08-17 22:56         ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 06/14] kernel-doc: public/grant_table.h Stefano Stabellini
2020-08-07 12:59   ` Jan Beulich
2020-08-07 21:51     ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 07/14] kernel-doc: public/hypfs.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 08/14] kernel-doc: public/memory.h Stefano Stabellini
2020-08-07 13:07   ` Jan Beulich
2020-08-07 21:51     ` Stefano Stabellini
2020-08-17 15:32       ` Jan Beulich
2020-08-17 22:56         ` Stefano Stabellini
2020-08-18  8:05           ` Jan Beulich
2020-08-20 23:20             ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 09/14] kernel-doc: public/sched.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 10/14] kernel-doc: public/vcpu.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 11/14] kernel-doc: public/version.h Stefano Stabellini
2020-08-07 13:12   ` Jan Beulich
2020-08-07 21:51     ` Stefano Stabellini
2020-08-06 23:49 ` [PATCH 12/14] kernel-doc: public/xen.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 13/14] kernel-doc: public/elfnote.h Stefano Stabellini
2020-08-06 23:49 ` [PATCH 14/14] kernel-doc: public/hvm/params.h Stefano Stabellini
2020-08-07  8:48 ` [PATCH 00/14] kernel-doc: public/arch-arm.h Jan Beulich
2020-08-07 21:51   ` Stefano Stabellini
2020-08-07 16:56 ` Stefano Stabellini
2020-08-18 12:52   ` Ian Jackson
2020-08-20 19:02     ` Stefano Stabellini

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=8b8a63fb-5b79-42ba-7d6f-d1538775033a@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=stefano.stabellini@xilinx.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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 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.