Round 15 projects

Previous projects, from round 14 are available here. For each project, if you click on the proposer's name, you may find more information.

dri-devel aka kernel GPU subsystem

In laptops, tablets, phones and lots of other places GPU/display uses more silicon die space than everything else combined (humans are mostly visual people after all), dri-devel (and the wider set of projects under the X.org Foundation's umbrella) is the community that makes this all work and shine.

We have a bunch of janitorial-type projects collected in https://dri.freedesktop.org/docs/drm/gpu/todo.html, varying from fairly mechanical to really challenging. We're also taking the usual array of checkpatch and coccinelle driven cleanup patches (they're great newbie starter patches). For an internship this means there's a lot of "build your own internship program", and we're definitely open to other projects. Just chat with mentors to start scoping a good project and what might be interesting for you.

Bit more PR for dri-devel: We're the subsystem that implemented the new shiny kernel-doc tooling and pushed for the conversion https://dri.freedesktop.org/docs/drm/gpu/index.html. We're the first ever kernel subsystem with a real CoC (and yes it's enforced)https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct. We're running our main trees with a much more participative model where all regular contributors have direct commit rights to relevant repos (instead of having to always jump through maintainers to get anything landed)http://blog.ffwll.ch/2016/09/commit-rights-in-the-linux-kernel.html. In short, we take newbie's and our contributor's needs in general very serious and try to care for them.

Best place to say hi to the community is by joining #dri-devel on freenode. You need a registered nick: https://freenode.net/kb/answer/registration

Mentors:: Daniel Vetter, Sean Paul

attribute documentation

Mentor:: Julia Lawall

The Linux kernel has many configurable parameters, declared as eg DEVICE_ATTR_RO. These should be represented in the kernel documentation, but many are not. The goal of this project will be to develop tools, likely using http://coccinelle.lip6.fr/:Coccinelle, to help collect information relevant to such documentation and to create an appropriate documentation skeleton, and then to work on filling in some such documentation, based on study of the code, comments, etc. Relevant tasks will appear on the page of the mentor.

nftables

Mentor:: Pablo Neira Ayuso

nftables provides a replacement for the very popular {ip,ip6,arp,eb}tables tools. nftables reuses most of the Netfilter components such as the existing hooks, connection tracking system, NAT, userspace queueing, logging among many other features. So we have only replaced the packet classification framework. nftables comes with a new userspace utility nft and the low-level userspace library libnftnl. The goal will be to help finish the translation layer software that converts from the iptables syntax to nftables, complete some simple missing features and fixing bugs whenever possible.

If you are interested in this project then:

• Install a fresh Linux kernel, from git sources, and latest git snapshots for libmnl, libnftnl and nftables. You can find more information on how to set up your enviroment at wiki.nftables.org.
• Make sure you understand basic operational of nftables, read existing documentation.
• Once you're fully set up, you got basic understanding of the tooling and everything is working on your side, then contact the mentor to request for an initial task.

For more information on nftables, please check: http://wiki.nftables.org

IIO driver

Mentors:: Daniel Baluta & Alison Schofield

A driver allows applications to communicate and control hardware devices. Each development cycle, driver changes account for more than a half of the total Linux kernel code changes.

The goal of this project is to write a driver for a sensor using the Industrial I/O interface. In the first part of the project you will get familiar with the hardware and the IIO subsystem then implement raw readings from the device. After upstreaming the code you will enhance the driver with advanced features such as support for buffered readings, power management and interrupts. The exact device will be decided when the internship starts.

We will provide you the hardware setup necessary to test the driver. If you are interested in this project please solve IIO_tasks.

For IIO patches, be sure to send them to linux-iio@vger.kernel.org