== Driver cleanups == {{attachment:messy-stairs.jpg}} 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. ''Required skills:'' Basic knowledge of the C language is needed, and the ability to build and boot a custom-built Linux kernel is desired. ''Mentors:'' Greg Kroah-Hartman [[GregKH|(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. Potential expansions to this project include: * Addressing more complex types of warnings, such as Sparse context warnings. * Adding new warning annotations, such as endianness annotations. * Writing custom analyses for new types of errors, using tools such as Sparse or Coccinelle. * Build-system related: Shrinking the kernel by adding new kernel configuration options to make built-in functionality optional or modular. [[http://thread.gmane.org/1344587169-18682-1-git-send-email-alex.page.kelly@gmail.com|Example 1]] [[http://mid.gmane.org/20130315155601.GB2931@leaf|Example 2]] [[http://mid.gmane.org/1358491462-16562-1-git-send-email-jmillenbach@gmail.com|Example 3]] * Advanced: Writing a GCC plugin to analyze the Linux kernel, porting across some warnings from Sparse. ''Required skills:'' Basic understanding of C, and the ability to build a Linux kernel. Mentor will provide extensive guidance on kernel warnings and how to analyze and fix them. ''Suggested reading:'' [[Sparse|Sparse tutorial]] from one of our past OPW interns. ''Mentor:'' Josh Triplett < josh@joshtriplett.org > == 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. You may find it helpful to look at systemd's existing support for generating QR codes on a text console. Some stretch goals of the project are: * Compression of the input stream so the QR code or barcode can be reduced in size. * Feed existing debugging mechanisms, such as objdump or nm, to pinpoint the cause of a crash (very far stretch goal, may not be feasible). * Build a smartphone app that can decode the kernel Oops for quick debugging (very far stretch goal, nice to have). ''Required skills:'' Basic understanding of C, and the ability to build a Linux kernel. Mentor will provide guidance on kernel internals and other topics for creating and analyzing kernel oops messages. ''Mentor:'' PJ Waskiewicz < peter.p.waskiewicz.jr@intel.com > == 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. Considerable time will be needed to understand how mm/swapfile.c::try_to_unuse() fits in with other parts of the memory management subsystem, especially as it relates to locking, and data structures. Main goals: * Remove quadratic complexity from try_to_unuse * Scan each process, and each shared memory area just once * Unuse swap entries from the desired swap area as they are encountered in that scan Stretch goals: * Improve the IO pattern for the new swapoff, by reading a larger cluster of swap entries from disk at once. * Deal with the corner case where there is not enough memory available to swap off one area, but pages have to be swapped back out to another swap area. ''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 [[RikvanRiel|(contact info)]] == RCU-Related Projects == Potential projects include: 1. Automatically Locate RCU Abuses 1. Inline __rcu_read_lock() __ 1. Add kmem_cache_free_rcu() 1. Validate RCU Algorithms 1. Automate Testing of RCU CPU Stall Warnings 1. Port RCU's KVM Scripts 1. Miscellaneous Fixes to RCU For more details on each project, please see [[http://kernelnewbies.org/OPWIntro-RCU|this page]]. ''Mentor:'' Paul E. McKenney < paulmck@linux.vnet.ibm.com > == Lguest Enhancements == 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: 1. Lguest does not allow guests to use the debug registers, but it could, if it was enhanced to switch them on guest entry and exit. 1. Implement virtio 1.0 draft standard devices in lguest: as a stretch goal, this could become a stress test for the linux virtio device implmentation. 1. Enhance lguest to use the mm notifiers to page out pages from the guest when they are paged from the controlling process. '''Mentor'':' Rusty Russell <[javascript:void(0);/*1384229010481*/ rusty@rustcorp.com.au ]> '''''