Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 13:42, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote work by a competent
> > programmer who is not yet familiar with the codebase. In
> > addition, they are:
> > - Well-defined - the scope is clear
> > - Self-contained - there are few dependencies
> > - Uncontroversial - they are acceptable to the community
> > - Incremental - they produce deliverables along the way
> >
> > Feel free to post ideas even if you are unable to mentor the project.
> > It doesn't hurt to share the idea!
> >
> > I will review project ideas and keep you up-to-date on QEMU's
> > acceptance into GSoC.
> >
> > Internship program details:
> > - Paid, remote work open source internships
> > - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> > hrs/week for 12 weeks
> > - Mentored by volunteers from QEMU, KVM, and rust-vmm
> > - Mentors typically spend at least 5 hours per week during the coding period
> >
> > Changes since last year: GSoC now has 175 or 350 hour project sizes
> > instead of 12 week full-time projects. GSoC will accept applicants who
> > are not students, before it was limited to students.
>
> I'm certainly up for mentoring new devices for vhost-device (rust-vmm
> vhost-user backends). Since we've become a code owner we're trying to
> clear the backlog (virto-vsock and virtio-block) but there are plenty of
> others that could be done. Of particular interest to me are:
>
>   - virtio-rpmb (we have a working C implementation I wrote)

Yes, it would be good to have an implementation. I mentioned this
device in my FOSDEM 22 talk about what's coming in VIRTIO 1.2:
https://vmsplice.net/~stefan/stefanha-fosdem-2022.pdf

>   - virtio-snd (in flight virtio spec)

There are QEMU patches in development by Shreyansh Chouhan although
that doesn't rule out a rust-vmm crate.

>   - virtio-video (again we have a working C version against v3)

Want to pick one device and write a project description for it?

> With my other hat on there are numerous TCG plugin projects that could
> be done. Adding basic plugins is fairly straight forward but it would be
> interesting to look at what is required to do a more involved plugin
> like panda-re's taint analysis (following ptrs as they move through the
> system). This will likely need some additional features exposed from the
> plugin interface to achieve.
>
> With that in mind there is also the idea of a central registry for
> register values which is a prerequisite for expanding access to TCG
> plugins but could also bring various quality of life improvements to
> other areas. I've written that up on a page:
>
>   https://wiki.qemu.org/Internships/ProjectIdeas/CentralRegisterRegistry

Thanks for posting that! Can you add links to the -d cpu, gdbstub, and
hmp/qmp register code? The idea is a little fuzzy in my mind, maybe
you could include a sketch of the API to give readers an idea of what
the project should deliver?

Stefan