qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH 2/8] docs: tweak kernel-doc for QEMU coding standards
Date: Fri, 2 Oct 2020 19:43:09 +0100	[thread overview]
Message-ID: <CAFEAcA_KXvADFm7uQX1a4peofK_On3DaFH2ZCUtWteaiABM-yA@mail.gmail.com> (raw)
In-Reply-To: <20201002183455.GF7303@habkost.net>

On Fri, 2 Oct 2020 at 19:35, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Mon, Dec 02, 2019 at 06:01:16PM +0000, Peter Maydell wrote:
> > On Fri, 29 Nov 2019 at 14:02, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > >
> > > Surprisingly, QEMU does have a pretty consistent doc comment style and
> > > it is not very different from the Linux kernel's.  Of the documentation
> > > "sigils", only "#" separates the QEMU doc comment style from Linux's,
> > > and it has 200+ instances vs. 6 for the kernel's '&struct foo' (all in
> > > accel/tcg/translate-all.c), so it's clear that the two standards are
> > > different in this respect.  In addition, our structs are typedefed and
> > > recognized by CamelCase names.
> > >
> > > Adjust kernel-doc's parser for these two aspects of the QEMU coding
> > > standards.  The patch has been valid, with hardly any change, for over
> > > two years, so it should not be an issue to keep kernel-doc in sync with
> > > the Linux copy.
> > >
> > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> [...]
> > > @@ -1906,7 +1914,9 @@ sub process_name($$) {
> > >             ++$warnings;
> > >         }
> > >
> > > -       if ($identifier =~ m/^struct\b/) {
> > > +       if ($identifier =~ m/^[A-Z]/) {
> > > +           $decl_type = 'type name';
> > > +       } elsif ($identifier =~ m/^struct\b/) {
> > >             $decl_type = 'struct';
> > >         } elsif ($identifier =~ m/^union\b/) {
> > >             $decl_type = 'union';
> >
> > The match for 'type name' is pretty wide but I guess
> > we can find out through experience if we need to narrow it.
>
> This change seems to make it impossible to document any macros
> with uppercase names.
>
> (for example, most of the macros in object.h are not included in
> the generated docs)
>
> What exactly is the purpose of the hunk above?

It's so that QEMU's bare type names like MemoryRegionSection get
recognized as being types. Kernel naming style always
prefers to say "struct MemoryRegionSection" where we use the
typedef and say "MemoryRegionSection", which is why the upstream
kernel-doc doesn't care about this. IIRC, without it, doc comments
which reference a type like '#TypeName' like:

     * @log_sync:
     *
     * Called by memory_region_snapshot_and_clear_dirty() and
     * memory_global_dirty_log_sync(), before accessing QEMU's "official"
     * copy of the dirty memory bitmap for a #MemoryRegionSection.
     *

don't correctly render the typename into a link to the
struct definition.

thanks
-- PMM


  reply	other threads:[~2020-10-02 18:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 14:02 [PATCH for-5.0 0/8] docs: integrate doc comments with Sphinx build Paolo Bonzini
2019-11-29 14:02 ` [PATCH 1/8] docs: import Linux kernel-doc script and extension Paolo Bonzini
2019-12-02 17:50   ` Peter Maydell
2019-11-29 14:02 ` [PATCH 2/8] docs: tweak kernel-doc for QEMU coding standards Paolo Bonzini
2019-12-02 18:01   ` Peter Maydell
2019-12-02 18:17     ` Paolo Bonzini
2020-10-02 18:34     ` Eduardo Habkost
2020-10-02 18:43       ` Peter Maydell [this message]
2020-10-02 18:46         ` Eduardo Habkost
2020-10-02 18:50           ` Paolo Bonzini
2020-10-02 19:18             ` Eduardo Habkost
2019-11-29 14:02 ` [PATCH 3/8] docs/conf.py: Enable use of kerneldoc sphinx extension Paolo Bonzini
2019-11-29 14:02 ` [PATCH 4/8] Makefile: disable Sphinx nitpicking Paolo Bonzini
2019-11-29 14:02 ` [PATCH 5/8] bitops.h: Silence kernel-doc complaints Paolo Bonzini
2019-11-29 14:02 ` [PATCH 6/8] docs: Create bitops.rst as example of kernel-docs Paolo Bonzini
2019-11-29 14:02 ` [PATCH 7/8] memory.h: Silence kernel-doc complaints Paolo Bonzini
2019-12-02 18:04   ` Peter Maydell
2019-11-29 14:02 ` [PATCH 8/8] docs: add memory API reference Paolo Bonzini
2019-12-02 18:05   ` Peter Maydell
2019-11-30  1:54 ` [PATCH for-5.0 0/8] docs: integrate doc comments with Sphinx build no-reply
2019-12-02 18:06 ` Peter Maydell
2019-12-02 18:13   ` Paolo Bonzini

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=CAFEAcA_KXvADFm7uQX1a4peofK_On3DaFH2ZCUtWteaiABM-yA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).