|
Size: 9006
Comment:
|
Size: 9773
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = FOSS Outreach Program for Women (OPW) = | ## page was renamed from OPWIntro = Outreachy (formerly FOSS Outreach Program for Women (OPW) and Project Ascend Alumni) = Please see the [https://www.gnome.org/outreachy/ Outreachy homepage] for an introduction to the program. |
| Line 3: | Line 5: |
| attachment:pinktux.png | The application period for '''Round 13''' will start on September 12, 2016. It's too early to send patches to the outreachy kernel mailing list, but please consider working through the other parts of the tutorial if you are interested in applying. |
| Line 5: | Line 7: |
| 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. | We are looking for round 13 [:OutreachySponsor:funding sponsors] and Linux kernel [:OutreachyMentor:mentors]. Please see the linked FAQ pages if you want to help out. Welcome Outreachy applicants! Our [:OutreachySponsor:round 13 sponsors] have generiously donated funds for internships for women, genderqueer, genderfluid, or genderfree people, and residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latino, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander 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. '''News''' This year, we ask that you send all patches to the appropriate staging driver maintainers, as well as to the outreachy mailing list. See [:FirstKernelPatch#submit_a_patch:Submit a patch] for more information. |
| Line 8: | Line 14: |
The official deadline for applying to OPW is May 8th. Please fill our your [https://live.gnome.org/OutreachProgramForWomen#Application_Process initial application] by May 8th, and then update by May 17th with your initial patch. 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 May 27th if they have been accepted. |
The application period for Outreachy Round 13 is September 12 to October 17. Please fill your [https://live.gnome.org/OutreachProgramForWomen#Application_Process application] by '''October 17''', and complete your kernel patch by '''October 17''' also (7pm UTC in both cases). Applicants that do not complete the first patch will not be considered for an internship. Please take a look at our [:OutreachyApply:application FAQ] for more info on how to fill out your application. |
| Line 12: | Line 17: |
| * 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 May 8th. * Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by May 17th. |
* Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list] * Join the #outreachy IRC channel on irc.gnome.org * Join the #kernel-outreachy IRC channel on irc.oftc.net * Read our [:OutreachyApply:instructions for applying], and apply by October 17. * Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by October 17. |
| Line 19: | Line 25: |
Interns may switch between projects, depending on how much work each project provides. This will allow interns the opportunity to learn about multiple kernel subsystems. Mentors from all three projects will be participating in patch review, answering questions, and providing advice for interacting with the kernel community. |
|
| Line 24: | Line 27: |
| == Ethernet == | Some projects may have small tasks you can complete as part of the application process. '''Do not''' start on these tasks until after you complete the [:Outreachyfirstpatch:first patch tutorial] and Greg Kroah-Hartman has accepted at least ten of your cleanup patches and two of your patchsets. In order to ensure applicants aren't working on the same task, we need your help in coordinating who is working on what task. Please see the [:OutreachyTasks:Outreachy tasks page] for details before starting on a task! |
| Line 26: | Line 29: |
| [http://lh6.ggpht.com/_KnE2M8e3X8Q/S6z4IPztwSI/AAAAAAAAE_Y/7O7nJuT8deQ/s200/130659908_922e26a071_b.jpg] | = Round 13 projects = Previous projects, from round 12 projects are available [:OutreachyRound13:here]. For each project, if you click on the proposer's name, you may find more information. |
| Line 28: | Line 32: |
| The Linux kernel ethernet drivers communicate with network hardware, to give you access to the Internet. Ethernet devices can be as simple as the 1 gigabit ethernet controllers in your laptop, to much faster ethernet controllers in servers. | == Coccinelle == ''Mentor:'': [:JuliaLawall:Julia Lawall] |
| Line 30: | Line 35: |
| Interns would work on the Intel 1 gigabit ethernet driver, igb and/or ethtool, the networking configuration userspace application that works with the drivers. Wired ethernet devices supported by igb are found in some laptops and most servers, but hardware will be provided if you don't have access to it. What will be required is a PCIe slot to put the any hardware you need into and at least one other system (laptop is fine, as long as it has an RJ45 network drop) to use as a link partner and a network cable to link them. | Coccinelle is a program matching and transformation tool that has been extensively used for improving Linux kernel code. This project will involve using Coccinelle to address a security issue in the Linux kernel. |
| Line 32: | Line 37: |
| ''Required skills'': Experience with Linux network configuation and basic C programming stills | The Linux kernel contains many data structures whose contents never change once they are initialized, many of which contain function pointers. Such structures that are modifiable at run time constitute a security risk, because an attacker may be able to overwrite the field value with a pointer to malicious code, that will then be executed with full kernel privileges. The first goal of this project is to use Coccinelle to insert const annotations on such structures to prevent runtime modfications. Some structures, however, cannot be made const, because they are initialized in several steps. In these cases, it may be possible to annotate the structure as {{{__ro_after_init}}}, if all of the initializations can take place during the init phase. The second goal is to add {{{__ro_after_init}}} where they are needed. This may requiring adding {{{__init}}} annotations on some code that is actually only needed during the init phase. |
| Line 34: | Line 39: |
| ''Optional but learnable skills:'' Knowledge of networking and networking features found in most ethernet devices. | More information about Coccinelle is available [http://coccinelle.lip6.fr/ here], including a [http://coccinelle.lip6.fr/papers/tutorial.pdf tutorial]. For some Coccinelle small tasks, click on the mentor name. |
| Line 36: | Line 41: |
| ''Mentors:'' Carolyn Wyborny [:CarolynWyborny:(contact info)] Anjali Jain [:AnjaliJain:(contact info)] | == IIO driver == ''Mentor:'': [:AlisonSchofield:Alison Schofield] and [:DanielBaluta:Daniel Baluta] |
| Line 38: | Line 44: |
| === USB === | 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. |
| Line 40: | Line 46: |
| attachment:usb-sushi.jpg | 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 you will enhance the driver with advanced features such as support for buffered readings, power management and interrupts. The exact device will be decided when the internship starts. |
| Line 42: | Line 48: |
| The Linux kernel includes a USB stack that communicates with the hardware behind your USB ports (USB host controller drivers), and includes USB device drivers that talk to your USB devices (USB device drivers). | 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:IIO tasks]. |
| Line 44: | Line 50: |
| Interns would work on the USB 3.0 host controller driver. The Linux kernel USB 3.0 host driver works 10 times faster than USB 2.0 host driver. The USB 3.0 driver still needs a lot of work, so there are plenty of small bug fixes that interns can tackle. If time permits, interns could also work on small to medium features. | == nftables == ''Mentor:'': [:pablo:Pablo Neira Ayuso] |
| Line 46: | Line 53: |
| USB 3.0 hardware will be provided to accepted interns if you don't have access to it. | 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. |
| Line 48: | Line 55: |
| ''Required skills'': Experience with manipulating linked lists in C, knowledge of basic boolean algrebra (bit masks and manipulating bits) | If you are interested in this project please consider solving any of the following tasks: |
| Line 50: | Line 57: |
| ''Optional but learnable skills'': Knowledge of USB or other low-level busses | * Request an account for the wiki.nftables.org page and help us improve the content. * Provide an iptables to nft translation via the iptables-translate utility. You can give a try to the following extensions: icmp, icmp6, rt. * Try to fix any of the existing nft bugs in bugzilla.netfilter.org. |
| Line 52: | Line 61: |
| ''Mentor'': Sarah Sharp [:SarahSharp:(contact info)] ''Suggested reading for accepted interns'': [http://lwn.net/Kernel/LDD3/ Linux Device Drivers] and [http://www.beyondlogic.org/usbnutshell/usb1.shtml USB in a Nutshell] |
For more information on nftables, please check: http://wiki.nftables.org |
| Line 57: | Line 64: |
| == x86 core == | == radix tree test suite == ''Mentors:'': [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox] |
| Line 59: | Line 67: |
| attachment:tux-hardware.jpg | The radix tree test suite (found in tools/testing/radix-tree) is currently rather ad-hoc. It would benefit from someone sorting through it, looking for missing coverage (maybe use gcov), and adding tests to exercise the missing functionality. This project involves working primarily in user-space as the kernel code is pulled into userspace and compiled there. |
| Line 61: | Line 69: |
| In the heart of the Linux kernel is code that runs directly on x86 processors. This includes early boot code, etc. | We could also use performance tests (Konstantin Khlebnikov recently posted patches that adds one performance test) |
| Line 63: | Line 71: |
| This part of the kernel is usually considered one of the more complex areas of the operating system. However, with a bit of guidance, it's really fascinating to see how a computer begins the journey from powered off to a blinking cursor at your login prompt. Interns would work alongside PJ on central boot code in the Linux kernel. Today, the kernel brings CPU's online one by one in a serial fashion. We can do better. Several stages of changes are planned to go from a completely serial approach to a fully parallel approach to bringing CPU's up. Interns would work on some of these planned changes. ''Required skills:'' Knowledge of how to use and manipulate pointers and function pointers in C is a must. ''Optional but learnable skills:'' Knowledge of computer architecture, x86 assembly ''Mentors:'' Peter Waskiewicz Jr (PJ) [:PeterWaskiewicz:(contact info)] == 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 live 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)] == Xen subsystem in Linux == attachment:be-zen-hack-xen.png The Linux kernel interfaces with the Xen hypervisor via hypercalls and also with other kernels by backend and frontend drivers. Xen's architecture allows to seperate each guest completlty and they can communicate amongst each other using backend/frontend drivers. But as any software exists there are bugs and the need to improve, cleanup and in general make it better. And also help in writting documentation on how Linux and Xen interact. The intern would work on a smörgåsbord of issues the Xen components in the Linux kernel has. The ones that fit within the three month period are concentrated in: * Making the event channel mechanism capable of fast checkpointing so that Remus (a software approach to lock-step and fail-over working) can properly work. * Multiple design issues with the block protocol (https://docs.google.com/document/d/1Vh5T8Z3Tx3sUEhVB0DnNDKBNiqB_ZA8Z5YVqAsCIjuI/edit). Also there are bugs in the code. * Multiple issues with the net protocol - lack of documentation (designs and internals), performance test and analysis, bug fixes etc. * Understanding the Xen platform and writing documentation on how it works to be made in an architecture paper (or doing this alongside the other projects and just writing down what has been learned). ''Required skills:'' Knowledge of how to use and manipulate pointers and function pointers in C is a must. ''Optional but learnable skills:'' Knowledge of computer architecture, x86 assembly ''Mentors:'' Konrad Rzeszutek Wilk [:KonradRzeszutekWilk:(contact info)] |
The radix tree test suite was adapted from outside the kernel tree recently, and does not yet share much of the common test infrastructure, eg tools/include/ |
| Line 125: | Line 74: |
| == radix tree __alloc_fd == ''Mentors:'': [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox] Currently sys_open() uses a linear search through a bitmap to find the first free file descriptor. This custom code could be replaced with the IDR interface. This replaces some custom code in the kernel with generic code (hopefully shrinking the size of the kernel), could result in some memory savings for processes with relatively few open files, and hopefully improve performance of workloads with very large numbers of open files. If you think you may be interested in this project, here are some small tasks to start with: * read how sys_open() currently finds the first open file descriptor, and allocates/resizes the file descriptor table * understand the IDR API * email Matthew and Rik a description of your findings, and a proposed project time line If you have any questions, please email Matthew and Rik. == radix tree PID allocation == ''Mentors:'': [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox] The PID allocator is a good match for the IDR API, but it currently uses its own custom allocator. Similar to the {{{__alloc_fd}}} project above, after understanding the IDR API, read how alloc_pid() works (paying particular attention to PID namespaces!) and come up with a project plan. == Project == ''Mentor:'': [:WikiName:Mentor names] Brief project description. |
|
| Line 126: | Line 98: |
| If you are interested in being a Linux kernel intern, please: | |
| Line 127: | Line 100: |
| 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 May 8th. * Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by May 17th. == Creative Commons Photo Credits == [http://tux.crystalxp.net/ Pink Tux], [http://www.flickr.com/photos/pfly/130659908/ Ethernet], [http://www.flickr.com/photos/zopeuse/56910709/ Tux on Hardware], [http://www.flickr.com/photos/paolomargari/4946053155/ Messy Stairs] |
* Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list] * Join the #outreachy IRC channel on irc.gnome.org * Join the #kernel-outreachy IRC channel on irc.oftc.net * Read our [:OutreachyApply:instructions for applying], and apply by October 17. * Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by October 17. * After you have 10 cleanup patches and at least two patchsets, choose some [:OutreachyTasks:small tasks] to complete. |
Outreachy (formerly FOSS Outreach Program for Women (OPW) and Project Ascend Alumni)
Please see the [https://www.gnome.org/outreachy/ Outreachy homepage] for an introduction to the program.
The application period for Round 13 will start on September 12, 2016. It's too early to send patches to the outreachy kernel mailing list, but please consider working through the other parts of the tutorial if you are interested in applying.
We are looking for round 13 [:OutreachySponsor:funding sponsors] and Linux kernel [:OutreachyMentor:mentors]. Please see the linked FAQ pages if you want to help out.
Welcome Outreachy applicants! Our [:OutreachySponsor:round 13 sponsors] have generiously donated funds for internships for women, genderqueer, genderfluid, or genderfree people, and residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latino, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander 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.
News This year, we ask that you send all patches to the appropriate staging driver maintainers, as well as to the outreachy mailing list. See [:FirstKernelPatch#submit_a_patch:Submit a patch] for more information.
How to apply
The application period for Outreachy Round 13 is September 12 to October 17. Please fill your [https://live.gnome.org/OutreachProgramForWomen#Application_Process application] by October 17, and complete your kernel patch by October 17 also (7pm UTC in both cases). Applicants that do not complete the first patch will not be considered for an internship. Please take a look at our [:OutreachyApply:application FAQ] for more info on how to fill out your application.
If you are interested in being a Linux kernel intern, please:
Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list]
- Join the #outreachy IRC channel on irc.gnome.org
- Join the #kernel-outreachy IRC channel on irc.oftc.net
Read our [:OutreachyApply:instructions for applying], and apply by October 17.
Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by October 17.
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.
Some projects may have small tasks you can complete as part of the application process. Do not start on these tasks until after you complete the [:Outreachyfirstpatch:first patch tutorial] and Greg Kroah-Hartman has accepted at least ten of your cleanup patches and two of your patchsets. In order to ensure applicants aren't working on the same task, we need your help in coordinating who is working on what task. Please see the [:OutreachyTasks:Outreachy tasks page] for details before starting on a task!
Round 13 projects
Previous projects, from round 12 projects are available [:OutreachyRound13:here]. For each project, if you click on the proposer's name, you may find more information.
Coccinelle
Mentor:: [:JuliaLawall:Julia Lawall]
Coccinelle is a program matching and transformation tool that has been extensively used for improving Linux kernel code. This project will involve using Coccinelle to address a security issue in the Linux kernel.
The Linux kernel contains many data structures whose contents never change once they are initialized, many of which contain function pointers. Such structures that are modifiable at run time constitute a security risk, because an attacker may be able to overwrite the field value with a pointer to malicious code, that will then be executed with full kernel privileges. The first goal of this project is to use Coccinelle to insert const annotations on such structures to prevent runtime modfications. Some structures, however, cannot be made const, because they are initialized in several steps. In these cases, it may be possible to annotate the structure as __ro_after_init, if all of the initializations can take place during the init phase. The second goal is to add __ro_after_init where they are needed. This may requiring adding __init annotations on some code that is actually only needed during the init phase.
More information about Coccinelle is available [http://coccinelle.lip6.fr/ here], including a [http://coccinelle.lip6.fr/papers/tutorial.pdf tutorial]. For some Coccinelle small tasks, click on the mentor name.
IIO driver
Mentor:: [:AlisonSchofield:Alison Schofield] and [:DanielBaluta: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 you will enhance the driver with advanced features such as 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:IIO tasks].
nftables
Mentor:: [:pablo: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:
- Request an account for the wiki.nftables.org page and help us improve the content.
- Provide an iptables to nft translation via the iptables-translate utility. You can give a try to the following extensions: icmp, icmp6, rt.
- Try to fix any of the existing nft bugs in bugzilla.netfilter.org.
For more information on nftables, please check: http://wiki.nftables.org
radix tree test suite
Mentors:: [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox]
The radix tree test suite (found in tools/testing/radix-tree) is currently rather ad-hoc. It would benefit from someone sorting through it, looking for missing coverage (maybe use gcov), and adding tests to exercise the missing functionality. This project involves working primarily in user-space as the kernel code is pulled into userspace and compiled there.
We could also use performance tests (Konstantin Khlebnikov recently posted patches that adds one performance test)
The radix tree test suite was adapted from outside the kernel tree recently, and does not yet share much of the common test infrastructure, eg tools/include/
radix tree __alloc_fd
Mentors:: [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox]
Currently sys_open() uses a linear search through a bitmap to find the first free file descriptor. This custom code could be replaced with the IDR interface. This replaces some custom code in the kernel with generic code (hopefully shrinking the size of the kernel), could result in some memory savings for processes with relatively few open files, and hopefully improve performance of workloads with very large numbers of open files.
If you think you may be interested in this project, here are some small tasks to start with:
- read how sys_open() currently finds the first open file descriptor, and allocates/resizes the file descriptor table
- understand the IDR API
- email Matthew and Rik a description of your findings, and a proposed project time line
If you have any questions, please email Matthew and Rik.
radix tree PID allocation
Mentors:: [:RikvanRiel:Rik van Riel] and [:MatthewWilcox:Matthew Wilcox]
The PID allocator is a good match for the IDR API, but it currently uses its own custom allocator. Similar to the __alloc_fd project above, after understanding the IDR API, read how alloc_pid() works (paying particular attention to PID namespaces!) and come up with a project plan.
Project
Mentor:: [:WikiName:Mentor names]
Brief project description.
Yeah, that sounds cool!
If you are interested in being a Linux kernel intern, please:
Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list]
- Join the #outreachy IRC channel on irc.gnome.org
- Join the #kernel-outreachy IRC channel on irc.oftc.net
Read our [:OutreachyApply:instructions for applying], and apply by October 17.
Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by October 17.
After you have 10 cleanup patches and at least two patchsets, choose some [:OutreachyTasks:small tasks] to complete.