Documentation/GettingStartedDevelopers

You want to contribute code, documentation or patches to QEMU?

Then...

• ... you should probably first join the mailing list.

Wiki

• Create yourselves an account in the QEMU wiki.
• Start with reading the QEMU wiki.
• Contribute to the QEMU wiki by adding new topics or improving and expanding existing topics. It should help you and others in the future.

Documentation

• Continue with reading the existing documentation.

Be prepared that all written documentation might be invalid - either because it is too old or because it was never correct. And it is never complete...

• If you find bugs in the documentation then fix them and send patches to the mailing list. See Contribute/ReportABug.

Code

• Get the code. If you want to be a developer, you almost certainly want to be building from git (see http://wiki.qemu.org/Download#Latest for the right tree)
• Run the QEMU system and user mode emulation for different targets (x86, mips, powerpc, ...). Images can be obtained from http://wiki.qemu.org/Download#QEMU_disk_images
• QEMU has a lot of different parts (hardware device emulation, target emulation, code generation for different hosts, configuration, ...).
  • Choose an interesting part and concentrate on it for some time and read the code.
• If you find bugs in the code, then fix them and send a patch to the mailing list (http://wiki.qemu.org/Contribute/SubmitAPatch)
  • Patches need to go the mailing list, and possibly also to a specific maintainer (read the MAINTAINERS text file in the top of the source code tree).
  • Read the HACKING and CODING_STYLE text files (in the top of the source code tree) before writing the patch
  • Run your patch through the "checkstyle.pl" script (found in the directory imaginatively called "scripts"). See http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html for how to hook it into git.
  • For very small, simple changes, you can do it as a single patch. If your change is more complex, you need to break it into smaller, separate patches (which together form a set of patches, or a patchset). Each step in the patch process can rely on previous patches, but not later patches - otherwise "git bisect" will break. This will require more effort on your part, but it saves a lot of work for everyone else.
  • If you have a lot of patches in a patchset (say five or more), then it may help to have a public git tree. You can get hosting from many places (repo.or.cz and github seem popular).

Getting to know the code

• QEMU does not have a high level design description document - only the source code tells the full story.
• There are some useful (although usually dated) descriptions on various parts of the wiki, and sometimes in mailing list descriptions:
  • Tracing framework is described at http://wiki.qemu.org/Features/Tracing
  • Some of the internal functionality (and a bit of the human monitoring / control interface) is implemented in QAPI and QMP (or will be migrated to it): http://wiki.qemu.org/Features/QAPI and http://wiki.qemu.org/QMP, plus http://www.linux-kvm.org/wiki/images/1/17/2010-forum-qmp-status-talk.pp.pdf
  • Related to the QMP changes is some proposed changes for configuration options known as QCFG: http://wiki.qemu.org/Features/QCFG
  • If you're into devices (new virtual hardware) it will help to know about QDEV: http://www.linux-kvm.org/wiki/images/f/fe/2010-forum-armbru-qdev.pdf

Bugs

• Read the Bug Tracker.
• Check for topics in it for which you feel capable of handling and try to fix the issue. Send patches.

Getting Help

• IRC might be useful. The #qemu channel is on irc://irc.oftc.net (note: no longer on Freenode).