qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
Date: Tue, 8 Nov 2016 16:20:44 +0000	[thread overview]
Message-ID: <20161108162044.GE11274@stefanha-x1.localdomain> (raw)
In-Reply-To: <bf3151dc-1236-c738-c473-d427996713e4@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

On Mon, Nov 07, 2016 at 05:52:37PM -0500, John Snow wrote:
> On 11/07/2016 08:30 AM, Stefan Hajnoczi wrote:
> > On Sat, Nov 05, 2016 at 06:42:23PM +0000, Peter Maydell wrote:
> > > In particular I think we could:
> > >  * set up a framework for our in-tree docs/ which gives us a
> > >    place to put new docs (both for-users and for-developers) --
> > >    I think having someplace to put things will reduce the barrier
> > >    to people writing useful new docs
> > >  * gradually convert the existing docs to rst
> > >  * use the sphinx extension features to pull in the doc-comments
> > >    we have been fairly consistently writing over the last few years
> > >    (for instance a converted version of docs/memory.txt could pull
> > >    in doc comments from memory.h; or we can just write simple
> > >    wrapper files like a "Bitmap operations" document that
> > >    displays the doc comments from bitops.h)
> > 
> > You are suggesting Sphinx for two different purposes:
> > 
> > 1. Formatting docs/ in HTML, PDF, etc.
> > 
> > 2. API documentation from doc comments.
> > 
> > It's a good idea for #1 since we can then publish automated builds of
> > the docs.  They will be easy to view and link to in a web browser.
> > 
> > I'm not a fan of #2.  QEMU is not a C library that people develop
> > against and our APIs are not stable.  There is no incentive for pretty
> > doc comments.  It might be cool to set it up once but things will
> > deterioate again quickly because we don't actually need external API
> > docs.
> > 
> > Instead of #2 we should focus on generating nice external QMP docs for
> > libvirt and other clients.  That has a clear benefit.
> > 
> > Stefan
> > 
> 
> I think that designating certain interfaces within QEMU as "Internal API"
> has some merit and are worth documenting for the sake of device/format
> authors like Peter suggests.

To be clear, I'm not saying QEMU doesn't need doc comments.  Every new
function in include/*.h must have doc comments and many .c internal
functions should too.

I'm just not enthusiastic about an effort to reformat doc comments and
make them render to HTML, PDF, etc in a nice way because I don't think
there's much payoff from doing that or maintaining it.

> I think at a minimum, having _A_ standard approach cannot possibly be *any*
> worse than _NO_ standard approach.

People don't follow the standard format and markup syntax since that
requires rendering and checking that the HTML, PDF, etc output looks
correct before submitting patches.

I guess one solution is to extend checkpatch.pl to enforce that all doc
comments follow a standard format.  It still cannot check that @, #, etc
are used in the right places but at least it can make sure that some
standard layout is followed.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2016-11-08 16:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-05 18:42 [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question) Peter Maydell
2016-11-07  9:35 ` Daniel P. Berrange
2016-11-07 13:30 ` Stefan Hajnoczi
2016-11-07 13:41   ` Daniel P. Berrange
2016-11-07 13:49   ` Peter Maydell
2016-11-07 22:52   ` John Snow
2016-11-08 16:20     ` Stefan Hajnoczi [this message]
2016-11-08 16:24       ` John Snow
2016-11-09 11:32         ` Stefan Hajnoczi
2016-11-10  3:39           ` Fam Zheng
2016-11-10  9:55             ` Stefan Hajnoczi
2016-11-10 10:08             ` Paolo Bonzini
2016-11-10 10:55               ` Daniel P. Berrange
2016-11-08 23:56   ` Paolo Bonzini
2016-11-07 15:03 ` Peter Maydell
2016-11-07 17:04   ` Paolo Bonzini
2016-11-07 17:20     ` Peter Maydell
2016-11-07 17:50       ` Paolo Bonzini
2016-11-07 18:23         ` Peter Maydell
2016-11-07 19:43           ` Paolo Bonzini
2016-11-07 20:36             ` Peter Maydell
2016-11-08  5:02   ` Emilio G. Cota
2017-01-05 16:47   ` 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=20161108162044.GE11274@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=jsnow@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 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).