|
Size: 7359
Comment:
|
Size: 9084
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 | '''Round 12''' is coming up soon. 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 intersted in applying. |
| Line 5: | Line 7: |
| Welcome OPW applicants! The Linux Foundation is sponsoring internships for women 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 12 [: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 11 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. |
| Line 8: | Line 12: |
The official deadline for applying to OPW is May 1st. However, the kernel project joined late, so that deadline is flexible. Please fill our your [https://live.gnome.org/OutreachProgramForWomen#Application_Process initial application], and then update by May 17th with your initial patch. Applicants will be notified by May 27th if they have been accepted. |
The application period for Outreachy Round 12 is February 9 to March 22. Please fill your [https://live.gnome.org/OutreachProgramForWomen#Application_Process application] by '''March 22''', and complete your kernel patch by '''March 22''' 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 15: |
| * Complete the [https://live.gnome.org/OutreachProgramForWomen#Application_Process application form] * Join the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list] and introduce yourself to the list * Join the #opw IRC channel on irc.gnome.org * Join the #kernel-opw IRC channel on irc.oftc.net |
* 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 March 22. * Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by March 22. |
| Line 18: | Line 23: |
| 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.'' | |
| 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. | 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 21: | Line 27: |
| Applicants for all projects should have basic experience with C or C++. 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.'' | = Round 12 projects = Previous projects, from round 11 projects are available [:OutreachyRound11:here]. For each project, if you click on the proposer's name, you may find more information. The following is a partial list of projects. More will come soon. |
| Line 23: | Line 30: |
| == Ethernet == | == Update legacy workqueue creation interface users == ''Mentor:'': [:Tejun Heo:Tejun Heo] |
| Line 25: | Line 33: |
| [http://lh6.ggpht.com/_KnE2M8e3X8Q/S6z4IPztwSI/AAAAAAAAE_Y/7O7nJuT8deQ/s200/130659908_922e26a071_b.jpg] | Workqueue is an asynchronous execution mechanism which is widely used across the kernel. A work item queued on a workqueue is asynchronously executed by a worker task (kworker/* in ps output). It's used for various purposes from simple context bouncing to hosting a persistent in-kernel service thread. |
| Line 27: | Line 35: |
| 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. | Due to its development history, there currently are two sets of interfaces to create workqueues. |
| Line 29: | Line 37: |
| 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. | * create[_singlethread|_freezable]_workqueue() * alloc[_ordered]_workqueue() |
| Line 31: | Line 40: |
| ''Required skills'': Experience with Linux network configuation and basic C programming stills | The latter is the new interface which is superset of the former. While each create*_workqueue() can be directly mapped to an alloc*_workqueue() invocation, create*_workqueue() encodes much less information than alloc*_workqueue() making determining which exact flavor and attributes to use non-trivial. Each case should be examined to find out why a specific kind is used and then converted to an alloc*_workqueue() invocation which matches the requirements. |
| Line 33: | Line 42: |
| ''Optional but learnable skills:'' Knowledge of networking and networking features found in most ethernet devices. | There currently are around 280 users of the legacy interface. While the number seems daunting, there are common patterns that many of them follow. |
| Line 35: | Line 44: |
| ''Mentors:'' Carolyn Wyborny [:CarolynWyborny:(contact info)] Anjali Jain [:AnjaliJain:(contact info)] | This project would involve understanding workqueue's various users to certain degree in addition to workqueue itself and can be a good opportunity to roam through and learn various parts of the kernel. |
| Line 37: | Line 46: |
| === USB === | See the small tasks for this project on the [:Tejun Heo: mentor's page]. |
| Line 39: | Line 48: |
| attachment:usb-sushi.jpg | == Coccinelle == ''Mentor:'': [:JuliaLawall:Julia Lawall] |
| Line 41: | Line 51: |
| 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). | Coccinelle is a program matching and transformation tool that has been extensively used for finding bugs in the Linux kernel. Around 50 Coccinelle rules are currently part of the kernel source code, and are regularly run on all kernel code changes via the 0-day build testing service. Still, there is the potential for many more such rules. The goal of this project is to prepare existing semantic patches, such as those found at [https://github.com/coccinelle/coccinellery coccinellery] for inclusion in the kernel and to write some new ones. 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 43: | Line 53: |
| 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. | == IIO driver == ''Mentor:'': [:DanielBaluta:Daniel Baluta] |
| Line 45: | Line 56: |
| USB 3.0 hardware will be provided to accepted interns if you don't have access to it. | 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 47: | Line 58: |
| ''Required skills'': Experience with manipulating linked lists in C, knowledge of basic boolean algrebra (bit masks and manipulating bits) | 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 we will enhance the driver with support for buffered readings, power management and interrupts. The exact device will be decided when the internship starts. |
| Line 49: | Line 60: |
| ''Optional but learnable skills'': Knowledge of USB or other low-level busses | 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 51: | Line 62: |
| ''Mentor'': Sarah Sharp [:SarahSharp:(contact info)] | == nftables == ''Mentor:'': [:pablo:Pablo Neira Ayuso] |
| Line 53: | Line 65: |
| ''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] | 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 55: | Line 67: |
| If you are interested in this project please consider solving any of the following tasks: | |
| Line 56: | Line 69: |
| == x86 core == | * 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. * Try to fix any of the existing nft bugs in bugzilla.netfilter.org. |
| Line 58: | Line 73: |
| attachment:tux-hardware.jpg | For more information on nftables, please check: http://wiki.nftables.org |
| Line 60: | Line 75: |
| In the heart of the Linux kernel is code that runs directly on x86 processors. This includes early boot code, etc. | == memory management latency tracing == ''Mentor:'' [:RikvanRiel:Rik van Riel] |
| Line 62: | Line 78: |
| 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. | Every few months, some issue seems to pop up where users suffer from excessive latency at page fault and/or memory allocation time, usually (but not always) due to latency in the page reclaim code. Developers end up with some ad-hoc tracing to figure out the problem, because the kernel does not have a tool to discover the cause of these latencies on production systems. The goal of this project is to add the necessary tracepoints to the page fault, memory allocation, compaction, and reclaiming code, as well as some kind of script or tool in userspace that allows Linux users to obtain information on where time was spent when a memory allocation takes longer than a specified threshold. |
| Line 64: | Line 80: |
| 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. | This project requires learning about the memory management code, as well as tracepoints, and tracing tools in userspace. |
| Line 66: | Line 82: |
| ''Required skills:'' Knowledge of how to use and manipulate pointers and function pointers in C is a must. | == Project == ''Mentor:'': [:WikiName:Mentor names] |
| Line 68: | Line 85: |
| ''Optional but learnable skills:'' Knowledge of computer architecture, x86 assembly ''Mentors:'' Peter Waskiewicz Jr (PJ) [:PeterWaskiewicz:(contact info)] == Driver cleanups == 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)] |
Brief project description. |
| Line 100: | Line 88: |
| If you are interested in being a Linux kernel intern, please: | |
| Line 101: | Line 90: |
If you are interested in being a Linux kernel intern, please: * Complete the [https://live.gnome.org/OutreachProgramForWomen#Application_Process application form] * Join the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list] and introduce yourself to the list |
* Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list] |
| Line 106: | Line 92: |
| * Join the #kernel-opw IRC channel (coming soon) Our guide to [:OPWfirstpatch:sending your first patch] is still a work in progress. You will be given a chance to update your application with your patch by May 17th. Please make sure your initial application is in by May 1st. == 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] |
* Join the #kernel-outreachy IRC channel on irc.oftc.net * Read our [:OutreachyApply:instructions for applying], and apply by March 22. * Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by March 22. * After you have sent several cleanup patches and at least one patchset, choose a [:OutreachyTasks:small task] 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.
Round 12 is coming up soon. 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 intersted in applying.
We are looking for round 12 [: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 11 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.
How to apply
The application period for Outreachy Round 12 is February 9 to March 22. Please fill your [https://live.gnome.org/OutreachProgramForWomen#Application_Process application] by March 22, and complete your kernel patch by March 22 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 March 22.
Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by March 22.
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 12 projects
Previous projects, from round 11 projects are available [:OutreachyRound11:here]. For each project, if you click on the proposer's name, you may find more information. The following is a partial list of projects. More will come soon.
Update legacy workqueue creation interface users
Mentor:: [:Tejun Heo:Tejun Heo]
Workqueue is an asynchronous execution mechanism which is widely used across the kernel. A work item queued on a workqueue is asynchronously executed by a worker task (kworker/* in ps output). It's used for various purposes from simple context bouncing to hosting a persistent in-kernel service thread.
Due to its development history, there currently are two sets of interfaces to create workqueues.
- create[_singlethread|_freezable]_workqueue()
- alloc[_ordered]_workqueue()
The latter is the new interface which is superset of the former. While each create*_workqueue() can be directly mapped to an alloc*_workqueue() invocation, create*_workqueue() encodes much less information than alloc*_workqueue() making determining which exact flavor and attributes to use non-trivial. Each case should be examined to find out why a specific kind is used and then converted to an alloc*_workqueue() invocation which matches the requirements.
There currently are around 280 users of the legacy interface. While the number seems daunting, there are common patterns that many of them follow.
This project would involve understanding workqueue's various users to certain degree in addition to workqueue itself and can be a good opportunity to roam through and learn various parts of the kernel.
See the small tasks for this project on the [:Tejun Heo: mentor's page].
Coccinelle
Mentor:: [:JuliaLawall:Julia Lawall]
Coccinelle is a program matching and transformation tool that has been extensively used for finding bugs in the Linux kernel. Around 50 Coccinelle rules are currently part of the kernel source code, and are regularly run on all kernel code changes via the 0-day build testing service. Still, there is the potential for many more such rules. The goal of this project is to prepare existing semantic patches, such as those found at [https://github.com/coccinelle/coccinellery coccinellery] for inclusion in the kernel and to write some new ones. 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:: [: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 we will enhance the driver with 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.
- Try to fix any of the existing nft bugs in bugzilla.netfilter.org.
For more information on nftables, please check: http://wiki.nftables.org
memory management latency tracing
Mentor: [:RikvanRiel:Rik van Riel]
Every few months, some issue seems to pop up where users suffer from excessive latency at page fault and/or memory allocation time, usually (but not always) due to latency in the page reclaim code. Developers end up with some ad-hoc tracing to figure out the problem, because the kernel does not have a tool to discover the cause of these latencies on production systems. The goal of this project is to add the necessary tracepoints to the page fault, memory allocation, compaction, and reclaiming code, as well as some kind of script or tool in userspace that allows Linux users to obtain information on where time was spent when a memory allocation takes longer than a specified threshold.
This project requires learning about the memory management code, as well as tracepoints, and tracing tools in userspace.
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 #opw 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 March 22.
Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by March 22.
After you have sent several cleanup patches and at least one patchset, choose a [:OutreachyTasks:small task] to complete.