mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
660e8d0f0b
qemu/docs/devel/index.rst

45 lines
723 B
ReStructuredText
Raw Normal View History

docs: Provide separate conf.py for each manual we want By default Sphinx wants to build a single manual at once. For QEMU, this doesn't suit us, because we want to have separate manuals for "Developer's Guide", "User Manual", and so on, and we don't want to ship the Developer's Guide to end-users. However, we don't want to completely duplicate conf.py for each manual, and we'd like to continue to support "build all docs in one run" for third-party sites like readthedocs.org. Make the top-level conf.py support two usage forms: (1) as a common config file which is included by the conf.py for each of QEMU's manuals: in this case sphinx-build is run multiple times, once per subdirectory. (2) as a top level conf file which will result in building all the manuals into a single document: in this case sphinx-build is run once, on the top-level docs directory. Provide per-manual conf.py files and top level pages for our first two manuals: * QEMU Developer's Guide (docs/devel) * QEMU System Emulation Management and Interoperability Guide (docs/interop) Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-id: 20190305172139.32662-9-peter.maydell@linaro.org Message-id: 20190228145624.24885-9-peter.maydell@linaro.org
2019-03-07 17:26:46 +03:00
.. This is the top level page for the 'devel' manual.
docs: simplify each section title Now that we merged into one doc, it makes the nav looks nicer. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210323074704.4078381-1-marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2021-03-23 10:47:04 +03:00
Developer Information
=====================
docs: Provide separate conf.py for each manual we want By default Sphinx wants to build a single manual at once. For QEMU, this doesn't suit us, because we want to have separate manuals for "Developer's Guide", "User Manual", and so on, and we don't want to ship the Developer's Guide to end-users. However, we don't want to completely duplicate conf.py for each manual, and we'd like to continue to support "build all docs in one run" for third-party sites like readthedocs.org. Make the top-level conf.py support two usage forms: (1) as a common config file which is included by the conf.py for each of QEMU's manuals: in this case sphinx-build is run multiple times, once per subdirectory. (2) as a top level conf file which will result in building all the manuals into a single document: in this case sphinx-build is run once, on the top-level docs directory. Provide per-manual conf.py files and top level pages for our first two manuals: * QEMU Developer's Guide (docs/devel) * QEMU System Emulation Management and Interoperability Guide (docs/interop) Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-id: 20190305172139.32662-9-peter.maydell@linaro.org Message-id: 20190228145624.24885-9-peter.maydell@linaro.org
2019-03-07 17:26:46 +03:00
This manual documents various parts of the internals of QEMU.
You only need to read it if you are interested in reading or
modifying QEMU's source code.
Contents:
.. toctree::
:maxdepth: 2
libqos/qgraph: format qgraph comments for sphinx documentation Change documentation style and fix minor typos in tests/qtest/libqos/qgraph.h to automatically generate sphinx documentation in docs/devel/qgraph.rst The mechanism explanation that once was in qgraph.h is now moved to qgraph.rst There is no functional change intended. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20210308073240.6363-1-eesposit@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-03-08 10:32:40 +03:00
:includehidden:
docs: Provide separate conf.py for each manual we want By default Sphinx wants to build a single manual at once. For QEMU, this doesn't suit us, because we want to have separate manuals for "Developer's Guide", "User Manual", and so on, and we don't want to ship the Developer's Guide to end-users. However, we don't want to completely duplicate conf.py for each manual, and we'd like to continue to support "build all docs in one run" for third-party sites like readthedocs.org. Make the top-level conf.py support two usage forms: (1) as a common config file which is included by the conf.py for each of QEMU's manuals: in this case sphinx-build is run multiple times, once per subdirectory. (2) as a top level conf file which will result in building all the manuals into a single document: in this case sphinx-build is run once, on the top-level docs directory. Provide per-manual conf.py files and top level pages for our first two manuals: * QEMU Developer's Guide (docs/devel) * QEMU System Emulation Management and Interoperability Guide (docs/interop) Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-id: 20190305172139.32662-9-peter.maydell@linaro.org Message-id: 20190228145624.24885-9-peter.maydell@linaro.org
2019-03-07 17:26:46 +03:00
docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document In an ideal world, we would all get along together very well, always be polite and never end up in huge conflicts. And even if there are conflicts, we would always handle each other fair and respectfully. Unfortunately, this is not an ideal world and sometimes people forget how to interact with each other in a professional and respectful way. Fortunately, this seldom happens in the QEMU community, but for such rare cases it is preferrable to have a basic code of conduct document available to show to people who are misbehaving. In case that does not help yet, we should also have a conflict resolution policy ready that can be applied in the worst case. The Code of Conduct document tries to be short and to the point while trying to remain friendly and welcoming; it is based on the Fedora Code of Conduct[1] with extra detail added based on the Contributor Covenant 1.3.0[2]. Other proposals included the Contributor Covenant 1.3.0 itself or the Django Code of Conduct[3] (which is also a derivative of Fedora's) but, in any case, there was agreement on keeping the conflict resolution policy separate from the CoC itself. An important point is whether to apply the code of conduct to violations that occur outside public spaces. The text herein restricts that to individuals acting as a representative or a member of the project or its community. This is intermediate between the Contributor Covenant (which only mentions representatives of the community, for example using an official project e-mail address or posting via an official social media account), and the Django Code of Conduct, which says that violations of this code outside these spaces "may" be considered but otherwise applies no limit. The conflict resolution policy is based on the Drupal Conflict Resolution Policy[4] and its derivative, the Mozilla Consequence Ladder[5]. [1] https://www.fedoraproject.com/code-of-conduct/ [2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/ [3] https://www.djangoproject.com/conduct/ [4] https://www.drupal.org/conflict-resolution [5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md Co-developed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Edmondson <david.edmondson@oracle.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-03-31 17:35:27 +03:00
code-of-conduct
conflict-resolution
docs: convert build system documentation to rST Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-11 19:34:40 +03:00
build-system
docs: move CODING_STYLE into the developer documentation There is no particular reason to keep this on it's own in the root of the tree. Move it into the rest of the fine developer manual and fixup any links to it. The only tweak I've made is to fix the code-block annotations to mention the language C. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210223095931.16908-1-alex.bennee@linaro.org>
2021-02-23 12:59:31 +03:00
style
kconfig: add documentation Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-12 15:06:51 +03:00
kconfig
docs: Add CFI Documentation Document how to compile with CFI and how to maintain CFI-safe code Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com> Message-Id: <20201204230615.2392-6-dbuono@linux.vnet.ibm.com> [Make build system section in index.rst and add the new file. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-05 02:06:15 +03:00
testing
fuzzing
control-flow-integrity
docs: Provide separate conf.py for each manual we want By default Sphinx wants to build a single manual at once. For QEMU, this doesn't suit us, because we want to have separate manuals for "Developer's Guide", "User Manual", and so on, and we don't want to ship the Developer's Guide to end-users. However, we don't want to completely duplicate conf.py for each manual, and we'd like to continue to support "build all docs in one run" for third-party sites like readthedocs.org. Make the top-level conf.py support two usage forms: (1) as a common config file which is included by the conf.py for each of QEMU's manuals: in this case sphinx-build is run multiple times, once per subdirectory. (2) as a top level conf file which will result in building all the manuals into a single document: in this case sphinx-build is run once, on the top-level docs directory. Provide per-manual conf.py files and top level pages for our first two manuals: * QEMU Developer's Guide (docs/devel) * QEMU System Emulation Management and Interoperability Guide (docs/interop) Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-id: 20190305172139.32662-9-peter.maydell@linaro.org Message-id: 20190228145624.24885-9-peter.maydell@linaro.org
2019-03-07 17:26:46 +03:00
loads-stores
memory
migration
atomics: convert to reStructuredText No attempts to fix or update the text; these are left for the next patch in the series. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-04-06 11:30:05 +03:00
atomics
docs: Provide separate conf.py for each manual we want By default Sphinx wants to build a single manual at once. For QEMU, this doesn't suit us, because we want to have separate manuals for "Developer's Guide", "User Manual", and so on, and we don't want to ship the Developer's Guide to end-users. However, we don't want to completely duplicate conf.py for each manual, and we'd like to continue to support "build all docs in one run" for third-party sites like readthedocs.org. Make the top-level conf.py support two usage forms: (1) as a common config file which is included by the conf.py for each of QEMU's manuals: in this case sphinx-build is run multiple times, once per subdirectory. (2) as a top level conf file which will result in building all the manuals into a single document: in this case sphinx-build is run once, on the top-level docs directory. Provide per-manual conf.py files and top level pages for our first two manuals: * QEMU Developer's Guide (docs/devel) * QEMU System Emulation Management and Interoperability Guide (docs/interop) Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-id: 20190305172139.32662-9-peter.maydell@linaro.org Message-id: 20190228145624.24885-9-peter.maydell@linaro.org
2019-03-07 17:26:46 +03:00
stable-process
docs: Move QTest documentation to its own document The qtest and libqtest doc comments will be parsed to generate API documentation, so move QTest documentation to its own document where the API and format documentation and will be included. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201005205228.697463-2-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-05 23:52:26 +03:00
qtest
decodetree: Move documentation to docs/devel/decodetree.rst One great big block comment isn't the best way to document the syntax of a language. Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-24 00:00:10 +03:00
decodetree
docs: add Secure Coding Practices to developer docs At KVM Forum 2018 I gave a presentation on security in QEMU: https://www.youtube.com/watch?v=YAdRf_hwxU8 (video) https://vmsplice.net/~stefan/stefanha-kvm-forum-2018.pdf (slides) This patch adds a guide to secure coding practices. This document covers things that developers should know about security in QEMU. It is just a starting point that we can expand on later. I hope it will be useful as a resource for new contributors and will save code reviewers from explaining the same concepts many times. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-id: 20190509121820.16294-2-stefanha@redhat.com Message-Id: <20190509121820.16294-2-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-05-09 15:18:19 +03:00
secure-coding-practices
Convert "translator internals" docs to RST, move to devel manual Our user-facing manual currently has a section "translator internals" which has some high-level information about the design of the TCG translator. This should really be in our new devel/ manual. Convert it to RST format and move it there. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190607152827.18003-2-peter.maydell@linaro.org Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-06-17 17:35:30 +03:00
tcg
docs/devel: add some notes on tcg-icount for developers This attempts to bring together my understanding of the requirements for icount behaviour into one reference document for our developer notes. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pavel Dovgalyuk <dovgaluk@ispras.ru> Cc: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200709141327.14631-3-alex.bennee@linaro.org>
2020-07-09 17:13:16 +03:00
tcg-icount
tracing: convert documentation to rST This is a simple rST conversion of the documentation. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20201216160923.722894-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-12-16 19:09:22 +03:00
tracing
docs/devel: convert and update MTTCG design document Do a light conversion to .rst and clean-up some of the language at the start now MTTCG has been merged for a while. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200709141327.14631-2-alex.bennee@linaro.org>
2020-07-09 17:13:15 +03:00
multi-thread-tcg
docs/devel: rename plugins.rst to tcg-plugins.rst This makes it a bit clearer what this is about. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-11-12 19:28:53 +03:00
tcg-plugins
docs: Create bitops.rst as example of kernel-docs Create a bitops.rst which is just a container for the kernel-doc comments in qemu/bitops.h. This is mostly a test of the kernel-doc extension machinery. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20190521122519.12573-7-peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-05-21 15:25:15 +03:00
bitops
docs/devel/reset.rst: add doc about Resettable interface Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200123132823.1117486-10-damien.hedde@greensocs.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 19:02:05 +03:00
reset
docs: rstfy s390 dasd ipl documentation While at it, also fix the numbering in 'What QEMU does'. Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20200213162942.14177-2-cohuck@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-01-28 15:24:14 +03:00
s390-dasd-ipl
docs/clocks: add device's clock documentation Add the documentation about the clock inputs and outputs in devices. This is based on the original work of Frederic Konrad. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 20200406135251.157596-6-damien.hedde@greensocs.com [PMM: Editing pass for minor grammar, style and Sphinx formatting fixes] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-04-17 18:56:33 +03:00
clocks
docs: Create docs/devel/qom.rst Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20200910221526.10041-9-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-11 01:15:25 +03:00
qom
scripts: add block-coroutine-wrapper.py We have a very frequent pattern of creating a coroutine from a function with several arguments: - create a structure to pack parameters - create _entry function to call original function taking parameters from struct - do different magic to handle completion: set ret to NOT_DONE or EINPROGRESS or use separate bool field - fill the struct and create coroutine from _entry function with this struct as a parameter - do coroutine enter and BDRV_POLL_WHILE loop Let's reduce code duplication by generating coroutine wrappers. This patch adds scripts/block-coroutine-wrapper.py together with some friends, which will generate functions with declared prototypes marked by the 'generated_co_wrapper' specifier. The usage of new code generation is as follows: 1. define the coroutine function somewhere int coroutine_fn bdrv_co_NAME(...) {...} 2. declare in some header file int generated_co_wrapper bdrv_NAME(...); with same list of parameters (generated_co_wrapper is defined in "include/block/block.h"). 3. Make sure the block_gen_c declaration in block/meson.build mentions the file with your marker function. Still, no function is now marked, this work is for the following commit. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200924185414.28642-5-vsementsov@virtuozzo.com> [Added encoding='utf-8' to open() calls as requested by Vladimir. Fixed typo and grammar issues pointed out by Eric Blake. Removed clang-format dependency that caused build test issues. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-24 21:54:11 +03:00
block-coroutine-wrapper
multi-process: add the concept description to docs/devel/qemu-multiprocess Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 02a68adef99f5df6a380bf8fd7b90948777e411c.1611938319.git.jag.raman@oracle.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-01-29 19:46:02 +03:00
multi-process
Reference in New Issue Copy Permalink