* Peter Maydell (peter.mayd...@linaro.org) 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 / dgilb...@redhat.com / Manchester, UK
