[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: should we have a new 'tools' manual?
From: |
Dr. David Alan Gilbert |
Subject: |
Re: should we have a new 'tools' manual? |
Date: |
Fri, 7 Feb 2020 15:24:13 +0000 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
* Peter Maydell (address@hidden) wrote:
> So far we've been converting docs to Sphinx and assigning them
> to manuals according to the division originally set out by
> Paolo on the wiki: https://wiki.qemu.org/Features/Documentation
>
> * QEMU User-mode Emulation User's Guide (docs/user)
> * QEMU System Emulation User's Guide (docs/system)
> * QEMU System Emulation Management and Interoperability Guide (docs/interop)
> * QEMU System Emulation Guest Hardware Specifications (docs/specs)
> * QEMU Developer's Guide (docs/devel, not shipped to end-users)
>
> but some of our documentation has always been a bit of an awkward
> fit into this classification:
> * qemu-img
> * qemu-nbd
> * virtfs-proxy-helper
> etc. I've tended to put these things into interop/.
>
> The proposal from Dan and David was that we should add a sixth
> top-level manual
> * QEMU Tools Guide (docs/tools)
>
> which would be a more coherent place for these to live.
>
> This seems like a good idea to me -- do people agree? What's
> our definition of a "tool", or do we just know one when we see it?
> What in particular should go in tools/ ?
The virtiofs security guide that Stefan wrote doesn't really fit in the
existing ones.
It's not about the use of qemu itself so it's not docs/user or
docs/system.
It's not specifying protocols or commands so it's not docs/interop.
It's not hardware.
And it's for end users not developers, so it's not docs/devel.
However, there's a question about whether it makes sense to bundle
the docs for all of the tools into one big manual when they're
really independent.
Dave
> thanks
> -- PMM
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK