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 1st. Please fill our your [https://live.gnome.org/OutreachProgramForWomen#Application_Process initial application] and complete your initial kernel patch by November 1st. 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 10th 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 1st.
Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by Nov 1st.
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
There are certain classes of compiler warnings that we should eliminate tree-wide and turn into errors. 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. Interns 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
Mentor: Zach Brown
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>
Mentors with TBD projects
[:RikvanRiel:Rik van Riel]
- Steven Rostedt
- 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 1st.
Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by Nov 1st.
Creative Commons Photo Credits
[http://tux.crystalxp.net/ Pink Tux], [http://www.flickr.com/photos/paolomargari/4946053155/ Messy Stairs]