Re: [Qemu-devel] [PATCH v6 10/25] replay: introduce breakpoint at the specified step

[Kashyap Chamarthy]

On Mon, Sep 24, 2018 at 07:38:28PM +0200, Paolo Bonzini wrote:
> On 24/09/2018 19:14, Peter Maydell wrote:
> > On 24 September 2018 at 17:50, Paolo Bonzini <address@hidden> wrote:
> >> On 24/09/2018 15:12, Peter Maydell wrote:
> >>> It got bumped by more important things
> >>> and also because somebody else said they were going to look at it,
> >>> and then it got bumped off *their* todo list by more important
> >>> things :-))
> >>
> >> I sense the force calling me... Well, my plans were did not actually
> >> involve GTKDoc and the developer documentation, but rather the rest of
> >> the manual.  What I wanted to do, but didn't manage to do, was to work
> >> on a new table of contents for the manual (not so much for the developer
> >> documentation), so that it could be converted to rST and generated with
> >> Sphinx.  Converting Texinfo to rST is not trivial, but it seems doable
> >> via makeinfo's Docbook backend and pandoc.
> > 
> > I think Kashyap was the other person who'd expressed interest
> > in doing something around Sphinx ?

Afraid, I couldn't manage my time to concentrate on the Sphinx stuff :-(
And I'm occupied with existing things on my plate until November; I'll
see if I can find some personal free time to get to this.

Currently what I have is the 10 documents from the docs/ directory that
are convereted to rST (some of them are already in QEMU Git); the below
rendering is built from QEMU 3.0):
https://kashyapc.fedorapeople.org/QEMU-Docs/_build/html/

TODO: Modify the Makefile in QEMU source to integrate Sphinx.

> Yes, but I think his interest was also more in user (he works on
> OpenStack) documentation than QEMU developer docuementation.

Yeah, FWIW, I'm fine with QMP interfaces, functional usage of various
QEMU APIs (I spent most time playing with the block layer),
command-line, and "things that libvirt consumes".  But for documenting
the internals (e.g. of emulated devices) such as structs, functions,
their parameters, return types, etc -- I don't have the relevant
in-depth expertise, as I don't spend a lot of time looking at QEMU code,
nor the time it takes to dig into, I'm afraid.

A decent chunk of the time I spend on QEMU is my own.  And given the
nature of my role (across the layers - OpenStack Nova, libvirt, and
QEMU), I am forever catching up with the relevant bits that I'm working
on, and struggle to effectively juggle it all; still learning.

    - - -

Given the complexity and breadth of QEMU, it's easy to imagine more than
a full-time role for high-quality user and developer documentation.  As
you need to spend time soaking into the code, actively follow the
upstream mailing list(s), try patch sets while they're in flux, write
test programs, and _then_ there is the "small matter of detailed
documentation".  Reminds me of the inimitable Michael Kerrisk of Linux
'man-pages'.

-- 
/kashyap