Google Summer of Code 2013

From QEMU

Introduction

QEMU is going to apply as a mentoring organization for Google Summer of Code 2013. This page contains our ideas list and information for students and mentors.

Preliminary information: This page is under construction as we plan to apply for 2013. Please contribute but remember that Google has not accepted organizations for 2013 yet.

Please note that QEMU, as a GSoC organization, also includes the following projects:

  • The Linux Kernel's KVM module
  • Libvirt, the virtualization library

Organization

Any Question, request or problem regarding QEMU in GSoC, please contact the following people. IRC is usually the quickest way to get an answer, see below for methods of communication.

Find Us

GSoC important pages

Information for students

We require students to provide at least the following information in their applications:

  • Contact information (email, irc nick, phone number)
  • A general personal description (skills, past experiences and open source contributions, if any)
  • Why QEMU and why this project
  • A detailed description of the approach the student will take

Please get in touch before applying so we can arrange for an IRC interview and get to know each other. Students who do not contact the mentor cannot be accepted.

VERY IMPORTANT: Submitting a patch and having it merged by QEMU or KVM increases your chances of being accepted.

Projects Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects, too. 

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

QEMU projects

Improving the Win32 and Win64 ports of QEMU

Summary: QEMU supports Windows (both 32-bit and 64-bit), but the limited amount of testing caused performance to suffer and bugs to creep in release after release. This project aims at fixing QEMU bugs affecting Windows platforms, and adding new features such as migration.

  • Skill level: intermediate/advanced
  • Language: C
  • Mentor: Paolo Bonzini
  • Suggested by: Paolo Bonzini

Add USB Media Transfer Protocol emulation to QEMU

Summary: Flesh out the prototype of MTP emulation and get the working result merged into QEMU.

There is a USB Media Transfer Protocol prototype which supports linux hosts. Media Transfer Protocol is a USB protocol used to exchange files with cameras, audio players, and smartphones. It is particularly interesting for QEMU because modern guest operating systems support it out-of-the-box and it can be used to easily transfer files between the guest and host.

High priority tasks:

  • Make it portable (i.e. work on windows hosts), evaluate options and implement it. Possible options: (1) create small posix/win32 abstraction layer for file+directory access, or (2) hook up virtfs code.
  • Finishing touches to get it into mergable state (not that much, little cleanups here and there).

Medium priority tasks:

  • Figure why Windows guests classify our MTP device as "Digital Camera" & fix it.
  • Test with different guests / guest applications, fix issues as they pop up.

Useful features which can be added:

  • Write support (current prototype is read-only).
  • Quota (so the guest can't fill up the hosts disk, obviously depends on write support).
  • Notification support: signal changes in the directory tree to the guest, so new/deleted files are instantly visible in the guest (probably hard to do in a efficient & portable way, maybe target linux+inotify).

For background information on MTP, see http://en.wikipedia.org/wiki/Media_Transfer_Protocol.

  • Skill level: intermediate/advanced
  • Language: C
  • Mentor: Gerd Hoffmann (kraxel)

KVM projects

Libvirt projects

Introducing job control to the storage driver

Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others.

  • Skill level: intermediate

More intelligent virsh auto-completion

Even though there's already some auto-completion in virsh, it is not enough. For better user experience, virsh should auto complete objects to virsh commands, e.g. "start <TAB><TAB>" lists not only options that the start command knows, but list of inactive domains as well. Moreover, the same applies to command options.

  • Skill level: beginner

Introduce API to query IP addresses for given domain

One of the most desired APIs in libvirt that still hasn't been implemented. The aim is to get/guess list of IP addresses assigned to domain. There are several ways to get such list: asking guest agent, snooping for domain traffic, parsing dnsmasq lease file, etc.

  • Skill level: beginner

Ability to run qemu-{system-}arm

Libvirt is nowadays tight to PCI bus based qemus: qemu-i386 and qemu-x86_64. However, with recent development of ARM architecture, as ARM based devices become more and more popular, the voice calling for ARM support in libvirt is getting stronger. The libvirt's assumption every domain has at least one PCI bus needs to be dropped and code adapted accordingly.

  • Skill level: advanced

Links:

Details:

  • Component: libvirt
  • Skill level: (see description to each item)
  • Language: C
  • Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
  • Suggested by: Michal Privoznik <mprivozn@redhat.com>

Information for mentors

Mentors are responsible for keeping in touch with their student and assessing the student's progress. GSoC has a mid-term evaluation and a final evaluation where both the mentor and student assess each other.

The mentor typically gives advice, reviews the student's code, and has regular communication with the student to ensure progress is being made.

Being a mentor is a significant time commitment, plan for 5 hours per week. Make sure you can make this commitment because backing out during the summer will affect the student's experience.

The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right student is critical so that both the mentor and the student can have a successful experience.

Retrieved from "https://wiki.qemu.org/index.php?title=Google_Summer_of_Code_2013&oldid=3447"