Not all Linux kernel drivers are immaculate, pristine, and perfect pieces of code. Specifically, the code that lives in the drivers/staging/ area of the Linux kernel source tree need lots of help and cleanups in order to get them up to the expected level of rosbustness and readability that the rest of the Linux kernel is known for.
These drivers all come with a TODO file that lists what needs to be done to them in order to get them cleaned up. These tasks range from the simple "fix coding style issues" and "remove unused code", to the more complex "port the driver to the proper wireless stack", so a wide range of skills can be learned if desired.
Interns would pick one of these drivers to clean up, submitting patches that address the TODO items, and eventually, help move it out of the staging area of the kernel, to the "proper" location. Having the hardware that is being controlled by these drivers is not necessary, but if desired, it can be found and shipped to the Intern doing the work.
Mentors: Greg Kroah-Hartman (contact info), Andy Grover, and Jacob Pan
Tree-wide warning fixes and static analysis enhancements
Compilers and other tools generate warnings of various kinds about code that looks questionable; those warnings sometimes indicate serious issues in the kernel, and at the very least represent areas for code cleanup.
There are certain classes of compiler warnings that we should eliminate tree-wide, and turn into errors so they can never return. For example, GCC's -Wmissing-prototypes and Sparse's -Wdecl warn about functions which should either be marked as static or have a declaration in an appropriate header file; fixing these warnings helps detect unused code in the kernel, allows the compiler to optimize more kernel code, and improves kernel code organization.
Interns working on this project would analyze the kernel build logs for these warnings, and write and submit patches to eliminate them. Ideally, interns should use cross-compilers to test the kernel for many different architectures, and ensure that no warnings of a given type exist on any major architecture, for either allyesconfig or allnoconfig. After eliminating all warnings of a particular type, interns would submit a final patch adding appropriate options like -Werror=missing-prototypes, preventing that warning from returning and earning the eternal gratitude of future kernel developers everywhere.
Suggested reading: Sparse tutorial from one of our past OPW interns.
Mentor: Josh Triplett < email@example.com >
Generate and decode QR codes for Linux kernel Oops messages and crashes
Linux kernel crash and error messages, also known as Oops messages, can be difficult to capture when they occur. Either too much information is coming out of the kernel and scrolls off the screen, or transcription of the information from the screen to a notepad can suffer from human error.
In order to ease the capture of these messages for better offline debugging, we would like to add a QR code or barcode encoding of the Oops message, and any other relevant debug information related to the crash/warning. This would be added to the Oops handlers inside the kernel, and would present the code as output into the framebuffer where kernel console messages are being sent.
The majority of this project will be researching existing QR code libraries that can be integrated into the kernel (i.e. GPLv2 or some other license that can be used in the kernel). The challenge is finding the right library, or develop your own, that can handle large amounts of input, as the kernel Oops messages can be quite large, relatively speaking. The libraries in question must be able to encode the incoming data, and have an easy way to decode the data into something human-readable for offline debugging of the crash.
Mentor: PJ Waskiewicz < firstname.lastname@example.org >
Reduce swapoff complexity from quadratic to linear
Currently swapoff reads each swap entry sequentially, and then scans all the processes and shared memory areas in the system, to find the user(s) of that swap entry. With the total amount of process memory and shared memory area space being M, and the total amount of swap being unused being S, that results in S*M work. On systems with 16GB worth of processes, and 2GB in swap, swapoff has been observed to take several hours.
The new swapoff code would scan across all processes and shared memory areas once, and swap in + free every swap entry from the swap area that the system wants to unuse. This would result in linear complexity, though potentially at the cost of having a worse IO pattern for swapoff.
Required skills: Basic understanding of C, the ability to build a Linux kernel are required. Experience with the use of locking to control concurrency, and understanding/untangling complex data structures is recommended. Mentor will provide guidance on kernel internals.
Mentor: Rik van Riel (contact info)
For more details on each project, please see this page.
Lguest is the tiny Linux hypervisor for 32-bit x86, and it lives entirely in the kernel source tree. It's quite fun to read and modify. There are several potential enhancements, in order of difficulty: