FOSS Outreach Program for Women (OPW)

Please see the [https://wiki.gnome.org/OutreachProgramForWomen FOSS Outreach Program for Women homepage] for an introduction to the program.

We are looking for round 7 [:OPWSponsor:funding sponsors] and Linux kernel [:OPWMentor:mentors]. Please see the linked FAQ pages if you want to help out.

attachment:pinktux.png

Welcome OPW applicants! The Linux Foundation is sponsoring internships for women and genderqueer/genderfluid people to work on the Linux kernel. The kernel is the most basic layer of the Linux operating system. It encompasses many things: hardware drivers, filesystems, security, task scheduling, and much more.

How to apply

The official application period for OPW Round 7 is October 1st to November 11th. Please fill our your [https://live.gnome.org/OutreachProgramForWomen#Application_Process initial application] and complete your initial kernel patch by November 11th. Applicants that do not complete the first patch will not be considered for an internship. Please take a look at our [:OPWApply:application FAQ] for more info on how to fill our your initial application. Applicants will be notified by November 25th if they have been accepted.

If you are interested in being a Linux kernel intern, please:

Join the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list]
Join the #opw IRC channel on irc.gnome.org
Join the #kernel-opw IRC channel on irc.oftc.net
Read our [:OPWApply:instructions for applying], and apply by Nov 11th.
Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by Nov 11th.

Participating Linux kernel projects

Applicants for all projects should have basic experience with C or C++ and boolean algebra. Optionally, we would love it if you have basic operating system knowledge, know your way around a Linux/UNIX command line, and/or know the revision system called git. Please note that these three skills can be learned during the internship.

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)] and Andy Grover

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>

BTRFS filesystem development

The BTRFS file system (playfully pronounced "butter F S") is an ambitious project to implement a Linux file system with advanced management and reliability features.

The BTRFS project is still under heavy initial development which presents an opportunity to contribute and make a difference. Interns will learn to work with the btrfs code while fixing small bugs and running their fixes through the test harness. The goal of the project is to implement a larger feature of the intern's choosing.

Pending btrfs features that might be suitable for an intern include, but are not limited to:

Removing the limit on the size of extent attributes
Adding support for storing system swap files in a btrfs file system
Enhancing the btrfs-progs userspace tool suite

Required skills: Basic understanding of C and the ability to build and boot a Linux kernel. Mentor will provide detailed guidance on kernel and btrfs internals and in setting up the building and testing workflow.

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)]

Mentors with TBD projects

Felipe Balbi

Yeah, that sounds cool!

If you are interested in being a Linux kernel intern, please:

Join the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list]
Join the #opw IRC channel on irc.gnome.org
Join the #kernel-opw IRC channel on irc.oftc.net
Read our [:OPWApply:instructions for applying], and apply by Nov 11th.
Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by Nov 11th.

Creative Commons Photo Credits

[http://tux.crystalxp.net/ Pink Tux], [http://www.flickr.com/photos/paolomargari/4946053155/ Messy Stairs]