Talk:Google Summer of Code 2019: Difference between revisions

From QEMU
(drafts moved to their own pages)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Drafts =


I'm saving some drafts here before including it on the wiki page. -[[User:Ehabkost|Ehabkost]] ([[User talk:Ehabkost|talk]]) 19:36, 16 January 2019 (UTC)
=== API documentation generation ===
'''Summary:''' Generation of API documentation from doc comments
QEMU currently has many functions documented using the GTK-Doc
syntax, but there is no mechanism to actually generate API
documentation from these doc comments.  We need build rules
that generate API documentation from C and Python source code.
Tasks:
* Picking a documentation generation tool and syntax (unclear if we should stay with GTK-Doc)
* Fixing or converting existing doc comments to the chosen syntax
* Writing build rules to generate the documentation
* Extra tasks, if time allows:
** Improving clarity or formatting of existing doc comments
** Converting existing ad-hoc comments in the code to doc comment syntax
** Add doc comments to existing APIs that are undocumented
'''Links:'''
* [https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01803.html series from 2011 for gtk-doc build integration]
* [https://www.mail-archive.com/qemu-devel@nongnu.org/msg411643.html discussion about Sphinx vs gtk-doc]
* [https://www.gtk.org/gtk-doc/ GTK-Doc Project]
'''Details:'''
* Skill level: beginner
* Language: C, Python
* Mentor: Eduardo Habkost <ehabkost@redhat.com> ("ehabkost" on IRC)
* Suggested by: Eduardo Habkost
=== Guest ABI automated testing ===
'''Summary:''' Automated test of Guest ABI and compatibility
QEMU tries to provide a stable '''guest ABI''' on versioned
machine-types.  Despite investing lots of effort keeping
compatibility, we have no automated testing to detect common
mistakes that break guest ABI.  It should be possible to write
automated test cases that will compare a virtual machine to a
previously stored dump of guest ABI information.
A guest ABI dump may include, for example:
* Data returned by CPUID instruction (or equivalent)
* Physical memory and I/O port maps
* Device addresses (PCI, USB, etc.)
* Device IDs and other guest-visible device fields
* Value of QOM properties that affect device behavior
This might require improving or adding new QMP commands to provide information to be validated by the automated test cases.  Some test cases may use a custom kernel image for collecting guest-visible data, or extending the qtest protocol.
'''Links:'''
* [https://github.com/autotest/tp-qemu/tree/master/qemu/deps/cpuid Ancient test code for CPUID compatibility]
* [https://github.com/ehabkost/qemu-hacks/commits/work/guest-abi-tests incomplete proof of concept for validating CPUID data]
* [https://github.com/ehabkost/gdb-qemu Hack that uses GDB to extract machine-type information from QEMU]
'''Details:'''
* Skill level: intermediate
* Language: C, Python
* Mentor: Eduardo Habkost <ehabkost@redhat.com> ("ehabkost" on IRC)
* Suggested by: Eduardo Habkost

Latest revision as of 18:51, 21 January 2019