[Top][All Lists]

[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
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.


> thanks
> -- PMM
Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

[Prev in Thread] Current Thread [Next in Thread]