Round 11 projects are available here. For each project, if you click on the proposer's name, you may find more information.

Update legacy workqueue creation interface users

Mentor:: Tejun_Heo

Workqueue is an asynchronous execution mechanism which is widely used across the kernel. A work item queued on a workqueue is asynchronously executed by a worker task (kworker/* in ps output). It's used for various purposes from simple context bouncing to hosting a persistent in-kernel service thread.

Due to its development history, there currently are two sets of interfaces to create workqueues.

The latter is the new interface which is superset of the former. While each create*_workqueue() can be directly mapped to an alloc*_workqueue() invocation, create*_workqueue() encodes much less information than alloc*_workqueue() making determining which exact flavor and attributes to use non-trivial. Each case should be examined to find out why a specific kind is used and then converted to an alloc*_workqueue() invocation which matches the requirements.

There currently are around 280 users of the legacy interface. While the number seems daunting, there are common patterns that many of them follow.

This project would involve understanding workqueue's various users to certain degree in addition to workqueue itself and can be a good opportunity to roam through and learn various parts of the kernel.

See the small tasks for this project on the mentor's page.


Mentor:: Julia Lawall

Coccinelle is a program matching and transformation tool that has been extensively used for finding bugs in the Linux kernel. Around 50 Coccinelle rules are currently part of the kernel source code, and are regularly run on all kernel code changes via the 0-day build testing service. Still, there is the potential for many more such rules. The goal of this project is to prepare existing semantic patches, such as those found at coccinellery for inclusion in the kernel and to write some new ones. An optional part of the project could be to improve the coccinellery infrastructure, which is currently a 500 line bash script. Please indicate in your application whether you are interested in this part of the project, however, interest in this part of the project is not a prerequisite for being selected as an intern.

More information about Coccinelle is available here, including a tutorial. For some Coccinelle small tasks, click on the mentor name.

IIO driver

Mentor:: Daniel Baluta

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 we will enhance the driver with 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 consider solving the IIO tasks.


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 please consider solving any of the following tasks:

For more information on nftables, please check:

memory management latency tracing

Mentor: Rik van Riel

Every few months, some issue seems to pop up where users suffer from excessive latency at page fault and/or memory allocation time, usually (but not always) due to latency in the page reclaim code. Developers end up with some ad-hoc tracing to figure out the problem, because the kernel does not have a tool to discover the cause of these latencies on production systems. The goal of this project is to add the necessary tracepoints to the page fault, memory allocation, compaction, and reclaiming code, as well as some kind of script or tool in userspace that allows Linux users to obtain information on where time was spent when a memory allocation takes longer than a specified threshold.

This project requires learning about the memory management code, as well as tracepoints, and tracing tools in userspace.

See the small tasks for this project on the mentor's page.

KernelNewbies: OutreachyRound12 (last edited 2017-12-30 01:30:13 by localhost)