Google Summer of Code 2024

Introduction

QEMU is applying for Google Summer of Code 2024. This page contains our ideas list and information for applicants and mentors. Google Summer of Code is an open source internship program offering paid remote work.

Status: Google will publish the list of accepted GSoC organizations at 18:00 UTC on February 21st. Applicants may get in touch with mentors before that date, but please don't invest too much time before accepted organizations are announced.

Application Process

1. Discuss the project idea with the mentor(s)

Read the project ideas list and choose one you are interested in. Read the links in the project idea description and start thinking about how you would approach this. Ask yourself:

• Do I have the necessary technical skills to complete this project?
• Will I be able to work independently without the physical presence of my mentor?

If you answer no to these questions, choose another project idea and/or organization that fits your skills.

Once you have identified a suitable project idea, email the mentor(s) your questions about the idea and explain your understanding of the project idea to them to verify that you are on the right track.

2. Submit your proposal

Upload your proposal PDF file to the Google Summer of Code website and notify your mentor(s) so they can give you feedback. You can make changes and upload the PDF again until the application deadline. Your proposal must include the following:

• Project idea (title)
• Your name and email address
• Outline of your solution
  • Do some background research by looking at source code, browsing relevant specifications, etc in order to decide how to tackle the project. Discuss any questions with your mentor. This section will explain how your solution will work.
• Project schedule
  • Create a week-by-week schedule of the coding period. Breaking down the project into tasks and estimate how many weeks they will take. The schedule can be adjusted during the summer so don't worry about getting everything right ahead of time.
• Relevant experience (programming language knowledge, hobby projects, etc)
• Are you available to work with no other commitments (jobs, university, vacation, etc) for the duration of your project? If not, please give details about the working hours and dates.

3. Contribution task

Once you have submitted your proposal PDF, let your mentor know and request a contribution task. The task will be a real bug or small feature that should not take more than 1 or 2 days to complete. This will allow you to demonstrate your skills in a realistic setting. Your mentor will provide you the details and help you with any questions.

Key Dates

From the timeline:

• February 21 18:00 UTC - Organizations and project ideas announced
• March 18 - April 2 18:00 UTC - Application period
• April 21 - Contribution task deadline
• May 1 18:00 UTC - Accepted applicants announced
• May 27 - August 26 - Standard coding period (an extended timeline is possible depending on your project)

Find Us

• IRC (GSoC specific): #qemu-gsoc on irc.oftc.net

• IRC (development):
  • QEMU: #qemu on irc.oftc.net
  • KVM: #kvm on chat.freenode.net

• Mailing lists:
  • QEMU: qemu-devel
  • KVM: linux-kvm

For general questions about QEMU in GSoC, please contact the following people:

• Stefan Hajnoczi <stefanha@gmail.com> (stefanha on IRC)

Project Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects, see #How to propose a custom project idea below.

GStreamer Backend for vhost-device-sound

Summary: Implement a GStreamer audio backend in rust-vmm's vhost-device-sound crate.

Project Description:

virtio-sound device emulation has recently been developed in the Rust vhost-device-sound crate. The crate currently contains audio backends for the ALSA and PipeWire sound APIs. The aim of this project is to build a new GStreamer audio backend.

Audio backends are written by implementing the AudioBackend trait. Refer to alsa.rs and pipewire.rs for examples of existing backends. The Stream and Buffer structs are used to transfer audio samples between the virtio-sound device and the sound API (e.g. GStreamer).

The backend should be implemented using the GStreamer Rust bindings. Mono and stereo playback and capture should be supported. The GStreamer pipelines for playback and capture will be hardcoded and only Linux needs to be supported.

Application Phase Tasks:

• Familiarize yourself with the vhost-device-sound crate's AudioBackend trait and Stream and Buffer structs.
• Familiarize yourself with the GStreamer Rust bindings.

Internship Tasks:

• Write a skeleton for the GStreamer audio backend in the vhost-device-sound crate. Reviewing how the ALSA and PipeWire backends work is a helpful guide.
• Implement playback functionality in the GStreamer audio backend for vhost-device-sound.
• Implement capture functionality in the GStreamer audio backend for vhost-device-sound.
• Implement automated tests with cargo test.
• Test the implementation with QEMU, which can act as a vhost-user frontend.
• As a stretch goal, contribute to the rust-vmm/vhost-device repo by fixing issues.

Links:

• vhost-device-sound crate
• GStreamer Rust bindings

Details:

• Project Size: 180 hrs
• Skill level: intermediate
• Language: Rust
• Mentors: Dorinda Bassey <dbassey@redhat.com>, Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
• Suggested by: Dorinda Bassey, Matias Ezequiel Vara Larsen

How to add a project idea

1. Create a new wiki page under "Internships/ProjectIdeas/YourIdea" and follow #Project idea template.
2. Add a link from this page like this: {{:Internships/ProjectIdeas/YourIdea}}

This is the listing of suggested project ideas. Students are free to suggest their own projects, see #How to propose a custom project idea below.

Project idea template

=== 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

How to propose a custom project idea

Applicants are welcome to propose their own project ideas. The process is as follows:

1. Email your project idea to qemu-devel@nongnu.org. CC Stefan Hajnoczi <stefanha@gmail.com> and regular QEMU contributors who you think might be interested in mentoring.
2. If a mentor is willing to take on the project idea, work with them to fill out the "Project idea template" above and email Stefan Hajnoczi <stefanha@gmail.com>.
3. Stefan will add the project idea to the wiki.

Note that other candidates can apply for newly added project ideas. This ensures that custom project ideas are fair and open.

How to get familiar with our software

See what people are developing and talking about on the mailing lists:

• qemu-devel
• libvir-list
• kvm

Grab the source code or browse it:

• qemu.git
• libvirt.git
• kvm.git

Build QEMU and run it: QEMU on Linux Hosts

Links

• Student Manual
• FAQ
• Timeline
• Advice for students applying (from 2011 but still relevant!)

Information for mentors

Mentors are responsible for keeping in touch with their intern and assessing progress. GSoC has evaluations where both the mentor and intern assess each other.

The mentor typically gives advice, reviews the intern's code, and has regular communication with the intern 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 intern's experience.

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