OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
a68e025bf5
qemu-e2k/docs/devel/index.rst

51 lines
861 B
ReStructuredText
Raw Normal View History

docs: standardize directory index to --- with overline Use a standard heading format for the index.rst file in a directory. Using overlines makes it clear that individual documents can use e.g. === for chapter titles and --- for section titles, as suggested in the Linux kernel guidelines[1]. They could do it anyway, because documents included in a toctree are parsed separately and therefore are not tied to the same conventions for headings. However, keeping some consistency is useful since sometimes files are included from multiple places. [1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-07 16:01:28 +02:00
---------------------
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 08:47:04 +01:00
Developer Information
docs: standardize directory index to --- with overline Use a standard heading format for the index.rst file in a directory. Using overlines makes it clear that individual documents can use e.g. === for chapter titles and --- for section titles, as suggested in the Linux kernel guidelines[1]. They could do it anyway, because documents included in a toctree are parsed separately and therefore are not tied to the same conventions for headings. However, keeping some consistency is useful since sometimes files are included from multiple places. [1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-07 16:01:28 +02:00
---------------------
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 15:26:46 +01:00
docs: Stop calling the top level subsections of our manual 'manuals' We merged our previous multiple-manual setup into a single Sphinx manual, but we left some text in the various index.rst lines that still calls the top level subsections separate 'manuals'. Update them to talk about "this section of the manual" instead, and remove now-obsolete comments about how the index.rst files are the "top level page for the 'foo' manual". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20210705095547.15790-3-peter.maydell@linaro.org
2021-07-05 11:55:42 +02:00
This section of the manual documents various parts of the internals of QEMU.
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 15:26:46 +01:00
You only need to read it if you are interested in reading or
modifying QEMU's source code.
.. 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 08:32:40 +01: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 15:26:46 +01: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 16:35:27 +02:00
code-of-conduct
conflict-resolution
docs: convert build system documentation to rST Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-11 18:34:40 +02: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 10:59:31 +01:00
style
kconfig: add documentation Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-12 13:06:51 +01: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 00:06:15 +01: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 15:26:46 +01: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 10:30:05 +02: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 15:26:46 +01:00
stable-process
Jobs based on custom runners: documentation and configuration placeholder As described in the included documentation, the "custom runner" jobs extend the GitLab CI jobs already in place. One of their primary goals of catching and preventing regressions on a wider number of host systems than the ones provided by GitLab's shared runners. This sets the stage in which other community members can add their own machine configuration documentation/scripts, and accompanying job definitions. As a general rule, those newly added contributed jobs should run as "non-gating", until their reliability is verified (AKA "allow_failure: true"). Signed-off-by: Cleber Rosa <crosa@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20210630012619.115262-2-crosa@redhat.com> Message-Id: <20210709143005.1554-2-alex.bennee@linaro.org>
2021-07-09 16:29:26 +02:00
ci
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 22:52:26 +02: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-23 22:00:10 +01: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 14:18:19 +02: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 16:35:30 +02: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 16:13:16 +02: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 17:09:22 +01: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 16:13:15 +02: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 17:28:53 +01: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 14:25:15 +02:00
bitops
ui: add clipboard documentation Document clipboard infrastructure in qemu. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20210519053940.1888907-1-kraxel@redhat.com Message-Id: <20210519053940.1888907-4-kraxel@redhat.com>
2021-05-19 07:39:34 +02:00
ui
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 17:02:05 +01: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 13:24:14 +01: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 17:56:33 +02: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 00:15:25 +02:00
qom
modules: hook up modules.h to docs build Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jose R. Ziviani <jziviani@suse.de> Message-Id: <20210624103836.2382472-25-kraxel@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-24 12:38:26 +02:00
modules
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 20:54:11 +02: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 17:46:02 +01:00
multi-process
docs: Added eBPF documentation. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2021-05-14 13:48:34 +02:00
ebpf_rss
docs/devel: Add VFIO device migration documentation Document interfaces used for VFIO device migration. Added flow of state changes during live migration with VFIO device. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Co-developed-by: Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by: Tarun Gupta <targupta@nvidia.com> Message-Id: <20210418122251.88809-1-targupta@nvidia.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-04-18 14:22:51 +02:00
vfio-migration
docs: convert qapi-code-gen.txt to ReST This is a very rudimentary conversion from .txt to .rst changing as little as possible, but getting it to render somewhat nicely; without using any Sphinx directives. (It is 'native' ReST.) Further patches will add cross-references and Sphinx-specific extensions to make it sparkle. Signed-off-by: John Snow <jsnow@redhat.com> Message-Id: <20210720235619.2048797-2-jsnow@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2021-07-21 01:56:17 +02:00
qapi-code-gen
docs/devel: rename file for writing monitor commands The file already covers writing HMP commands, in addition to the QMP commands, so it deserves a more general name. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-09-09 17:54:02 +02:00
writing-monitor-commands
docs: rSTify the "TrivialPatches" wiki The original wiki is here[1]. I converted by copying the wiki source into a .wiki file and convert to rST using `pandoc`: $ pandoc -f Mediawiki -t rst trivial-patches.wiki -o trivial-patches.rst Update the active maintainer names (and drop Michael Tokarev's inactive repo) to reflect current reality. [1] https://wiki.qemu.org/Contribute/TrivialPatches Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211110144902.388183-2-kchamart@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-11-10 15:49:00 +01:00
trivial-patches
docs: rSTify the "SubmitAPatch" wiki - The original wiki is here[1]. I copied the wiki source[2] into a .wiki file, and used `pandoc` to convert it to rST: $> pandoc -f Mediawiki -t rst submitting-a-patch.wiki -o submitting-a-patch.rst - The only minor touch-ups I did was to fix URLs. But 99%, it is a 1-1 conversion. (An example of a "touch-up": under the section "Patch emails must include a Signed-off-by: line", I updated the "see SubmittingPatches 1.12" to "1.12) Sign your work") - I have also converted a couple other related wiki pages (included in this patch series) that were hyperlinked within the SubmitAPatch page, or a page that it refers to: - SubmitAPullRequest: https://wiki.qemu.org/Contribute/SubmitAPullRequest - TrivialPatches: https://wiki.qemu.org/Contribute/TrivialPatches - Over time, many people contributed to this wiki page; you can find all the authors in the wiki history[3]. [1] https://wiki.qemu.org/Contribute/SubmitAPatch [2] http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch&action=edit [3] http://wiki.qemu.org/index.php?title=Contribute/SubmitAPatch&action=history Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Message-Id: <20211110144902.388183-4-kchamart@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [thuth: Cosmetic fixes] Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-11-10 15:49:02 +01:00
submitting-a-patch
docs: rSTify the "SubmitAPullRequest" wiki The original wiki is here[1]. I converted by copying the wiki source into a .wiki file and convert to rST using `pandoc`: $ pandoc -f Mediawiki -t rst submitting-a-pull-request.wiki \ -o submitting-a-pull-request.rst This is a 1-1 conversion; no content changes. [1] https://wiki.qemu.org/Contribute/SubmitAPullRequest Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211110144902.388183-3-kchamart@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-11-10 15:49:01 +01:00
submitting-a-pull-request
Reference in New Issue Copy Permalink