8764
Comment:
|
8916
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
Please see the [https://www.gnome.org/outreachy/ Outreachy homepage] for an introduction to the program. | Please see the [[https://www.gnome.org/outreachy/|Outreachy homepage]] for an introduction to the program. |
Line 5: | Line 5: |
'''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. | The application period for '''Round 16''' will start in mid February, 2018. 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 7: | Line 7: |
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. | We are looking for round 15 [[OutreachySponsor|funding sponsors]] and Linux kernel [[OutreachyMentor|mentors]]. Please see the linked FAQ pages if you want to help out. |
Line 9: | Line 9: |
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. | Welcome Outreachy applicants! Our [[OutreachySponsor|round 15 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. '''For IIO patches, be sure to send them to linux-iio@vger.kernel.org''' |
Line 12: | Line 14: |
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. | The application period for Outreachy Round 15 is September 7 to October 23. Please fill your [[https://live.gnome.org/OutreachProgramForWomen#Application_Process|application]] by '''October 23''', and complete your kernel patch by '''October 23''' 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 16: | Line 18: |
* Join the [https://groups.google.com/forum/#!forum/outreachy-kernel outreachy-kernel mailing list] | * Join the [[https://groups.google.com/forum/#!forum/outreachy-kernel|outreachy-kernel mailing list]] |
Line 19: | Line 21: |
* 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. |
* Read our [[OutreachyApply|instructions for applying]], and apply by October 23. * Use our [[Outreachyfirstpatch|tutorial]] to send in your first kernel patch by October 23. |
Line 25: | Line 27: |
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! | 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 27: | Line 29: |
= 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. |
= Round 15 projects = Previous projects, from round 14 projects are available [[OutreachyRound14|here]]. For each project, if you click on the proposer's name, you may find more information. |
Line 30: | Line 32: |
== Update legacy workqueue creation interface users == ''Mentor:'': [:Tejun Heo:Tejun Heo] |
== dri-devel aka kernel GPU subsystem == |
Line 33: | Line 34: |
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. | In laptops, tablets, phones and lots of other places GPU/display uses more silicon die space than everything else combined (humans are mostly visual people after all), dri-devel (and the wider set of projects under the X.org Foundation's umbrella) is the community that makes this all work and shine. |
Line 35: | Line 36: |
Due to its development history, there currently are two sets of interfaces to create workqueues. | We have a bunch of janitorial-type projects collected in [[https://dri.freedesktop.org/docs/drm/gpu/todo.html]], varying from fairly mechanical to really challenging. We're also taking the usual array of checkpatch and coccinelle driven cleanup patches (they're great newbie starter patches). For an internship this means there's a lot of "build your own internship program", and we're definitely open to other projects. Just chat with mentors to start scoping a good project and what might be interesting for you. |
Line 37: | Line 38: |
* create[_singlethread|_freezable]_workqueue() * alloc[_ordered]_workqueue() |
Bit more PR for dri-devel: We're the subsystem that implemented the new shiny kernel-doc tooling and pushed for the conversion [[https://dri.freedesktop.org/docs/drm/gpu/index.html]]. We're the first ever kernel subsystem with a real CoC (and yes it's enforced)[[https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct]]. We're running our main trees with a much more participative model where all regular contributors have direct commit rights to relevant repos (instead of having to always jump through maintainers to get anything landed)[[http://blog.ffwll.ch/2016/09/commit-rights-in-the-linux-kernel.html]]. In short, we take newbie's and our contributor's needs in general very serious and try to care for them. |
Line 40: | Line 40: |
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. | Best place to say hi to the community is by joining #dri-devel on freenode. You need a registered nick: https://freenode.net/kb/answer/registration |
Line 42: | Line 42: |
There currently are around 280 users of the legacy interface. While the number seems daunting, there are common patterns that many of them follow. | ''Mentors:'': [[Daniel_Vetter|Daniel Vetter]], [[SeanPaul|Sean Paul]] |
Line 44: | Line 44: |
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. | == attribute documentation == ''Mentor:'': [[JuliaLawall|Julia Lawall]] |
Line 46: | Line 47: |
See the small tasks for this project on the [:Tejun Heo: mentor's page]. | The Linux kernel has many configurable parameters, declared as eg DEVICE_ATTR_RO. These should be represented in the kernel documentation, but many are not. The goal of this project will be to develop tools, likely using [[http://coccinelle.lip6.fr/:Coccinelle]], to help collect information relevant to such documentation and to create an appropriate documentation skeleton, and then to work on filling in some such documentation, based on study of the code, comments, etc. Relevant tasks will appear on the page of the mentor. |
Line 48: | Line 49: |
== Coccinelle == ''Mentor:'': [:JuliaLawall:Julia Lawall] |
== nftables == ''Mentor:'': [[pablo|Pablo Neira Ayuso]] |
Line 51: | Line 52: |
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. | 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 then: * Install a fresh Linux kernel, from git sources, and latest git snapshots for libmnl, libnftnl and nftables. You can find more information on how to set up your enviroment at wiki.nftables.org. * Make sure you understand basic operational of nftables, read existing documentation. * Once you're fully set up, you got basic understanding of the tooling and everything is working on your side, then contact the mentor to request for an initial task. For more information on nftables, please check: http://wiki.nftables.org |
Line 54: | Line 63: |
''Mentor:'': [:DanielBaluta:Daniel Baluta] | ''Mentors:'': [[DanielBaluta|Daniel Baluta]] & [[AlisonSchofield|Alison Schofield]] |
Line 58: | Line 67: |
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. | 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 60: | Line 69: |
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]. | We will provide you the hardware setup necessary to test the driver. If you are interested in this project please solve [[IIO_tasks]]. |
Line 62: | Line 71: |
== 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. For more information on nftables, please check: http://wiki.nftables.org == page allocation & reclaim 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. |
'''For IIO patches, be sure to send them to linux-iio@vger.kernel.org''' |
Line 79: | Line 74: |
''Mentor:'': [:WikiName:Mentor names] | ''Mentor:'': [[WikiName|Mentor names]] |
Line 86: | Line 81: |
* 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 [[https://groups.google.com/forum/#!forum/outreachy-kernel|outreachy-kernel mailing list]] * Join the #outreachy IRC channel on irc.gnome.org |
Line 89: | Line 84: |
* 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. |
* Read our [[OutreachyApply|instructions for applying]], and apply by March 30. * Use our [[Outreachyfirstpatch|tutorial]] to send in your first kernel patch by March 30. * 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 Outreachy homepage for an introduction to the program.
The application period for Round 16 will start in mid February, 2018. 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 15 funding sponsors and Linux kernel mentors. Please see the linked FAQ pages if you want to help out.
Welcome Outreachy applicants! Our round 15 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 Submit a patch for more information. For IIO patches, be sure to send them to linux-iio@vger.kernel.org
How to apply
The application period for Outreachy Round 15 is September 7 to October 23. Please fill your application by October 23, and complete your kernel patch by October 23 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 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 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 instructions for applying, and apply by October 23.
Use our tutorial to send in your first kernel patch by October 23.
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 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 Outreachy tasks page for details before starting on a task!
Round 15 projects
Previous projects, from round 14 projects are available here. For each project, if you click on the proposer's name, you may find more information.
dri-devel aka kernel GPU subsystem
In laptops, tablets, phones and lots of other places GPU/display uses more silicon die space than everything else combined (humans are mostly visual people after all), dri-devel (and the wider set of projects under the X.org Foundation's umbrella) is the community that makes this all work and shine.
We have a bunch of janitorial-type projects collected in https://dri.freedesktop.org/docs/drm/gpu/todo.html, varying from fairly mechanical to really challenging. We're also taking the usual array of checkpatch and coccinelle driven cleanup patches (they're great newbie starter patches). For an internship this means there's a lot of "build your own internship program", and we're definitely open to other projects. Just chat with mentors to start scoping a good project and what might be interesting for you.
Bit more PR for dri-devel: We're the subsystem that implemented the new shiny kernel-doc tooling and pushed for the conversion https://dri.freedesktop.org/docs/drm/gpu/index.html. We're the first ever kernel subsystem with a real CoC (and yes it's enforced)https://dri.freedesktop.org/docs/drm/gpu/introduction.html#code-of-conduct. We're running our main trees with a much more participative model where all regular contributors have direct commit rights to relevant repos (instead of having to always jump through maintainers to get anything landed)http://blog.ffwll.ch/2016/09/commit-rights-in-the-linux-kernel.html. In short, we take newbie's and our contributor's needs in general very serious and try to care for them.
Best place to say hi to the community is by joining #dri-devel on freenode. You need a registered nick: https://freenode.net/kb/answer/registration
Mentors:: Daniel Vetter, Sean Paul
attribute documentation
Mentor:: Julia Lawall
The Linux kernel has many configurable parameters, declared as eg DEVICE_ATTR_RO. These should be represented in the kernel documentation, but many are not. The goal of this project will be to develop tools, likely using http://coccinelle.lip6.fr/:Coccinelle, to help collect information relevant to such documentation and to create an appropriate documentation skeleton, and then to work on filling in some such documentation, based on study of the code, comments, etc. Relevant tasks will appear on the page of the mentor.
nftables
Mentor:: 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 then:
- Install a fresh Linux kernel, from git sources, and latest git snapshots for libmnl, libnftnl and nftables. You can find more information on how to set up your enviroment at wiki.nftables.org.
- Make sure you understand basic operational of nftables, read existing documentation.
- Once you're fully set up, you got basic understanding of the tooling and everything is working on your side, then contact the mentor to request for an initial task.
For more information on nftables, please check: http://wiki.nftables.org
IIO driver
Mentors:: Daniel Baluta & Alison Schofield
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 solve IIO_tasks.
For IIO patches, be sure to send them to linux-iio@vger.kernel.org
Project
Mentor:: Mentor names
Brief project description.
Yeah, that sounds cool!
If you are interested in being a Linux kernel intern, please:
Join the 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 instructions for applying, and apply by March 30.
Use our tutorial to send in your first kernel patch by March 30.
After you have 10 cleanup patches and at least two patchsets, choose some small tasks to complete.