Talk:Google Summer of Code 2019: Difference between revisions
Line 13: | Line 13: | ||
Tasks: | Tasks: | ||
* Picking a documentation generation tool (unclear if we should stay with GTK-Doc) | * Picking a documentation generation tool and syntax (unclear if we should stay with GTK-Doc) | ||
* Fixing or converting existing | * Fixing or converting existing doc comments to the chosen syntax | ||
* Writing build rules to generate the documentation | * Writing build rules to generate the documentation | ||
* Extra tasks, if time allows: | * Extra tasks, if time allows: |
Revision as of 18:36, 21 January 2019
Drafts
I'm saving some drafts here before including it on the wiki page. -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:
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:
- Ancient test code for CPUID compatibility
- incomplete proof of concept for validating CPUID data
- 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