12943
Comment: Tinification
|
8770
bikeshed dri-devel section + add myself as mentor
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
= 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. |
## 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 4: | Line 5: |
We are looking for round 8 [:OPWSponsor:funding sponsors] and Linux kernel [:OPWMentor:mentors]. Please see the linked FAQ pages if you want to help out. | The application period for '''Round 15''' will start on September 7, 2017. 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 6: | Line 7: |
attachment:pinktux.png | 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 8: | Line 9: |
Welcome OPW applicants! Our [:OPWSponsor:round 8 sponsors] have generiously donated funds for 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. | 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 11: | Line 14: |
The application period for OPW Round 8 is Feb 25th to March 19th. Please fill our your [https://live.gnome.org/OutreachProgramForWomen#Application_Process initial application] and complete your initial kernel patch by March 19th. 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 on April 21st if they have been accepted. | 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 15: | Line 18: |
* 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 March 19th. * Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by March 19th. We also encourage all OPW applicants that are students to also apply to [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code], and in particular the [http://www.google-melange.com/gsoc/org2/google/gsoc2014/lf Linux Foundation projects]. The Google Summer of Code projects are separate from the projects listed below, so you will need to work on applications for both programs. |
* 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 23. * Use our [:Outreachyfirstpatch:tutorial] to send in your first kernel patch by October 23. |
Line 26: | Line 27: |
Round 8 (May to August 2014) projects: | 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 28: | Line 29: |
== Coccinelle == | = 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: |
[http://coccinelle.lip6.fr Coccinelle] is a program matching and transformation tool for C code that has been used extensively in contributing to the Linux kernel, for both both code evolutions and bug fixes. Coccinelle is driven by specifications, known as semantic patches, that use a notation based on C code, and are this fairly easy to develop. Around 40 semantic patches are included with the Linux kernel source code, in scripts/coccinelle, and are used in the continuous testing service provided by Intel. |
== dri-devel aka kernel GPU subsystem == |
Line 33: | Line 34: |
The goal of this internship is to help build up the set of semantic patches that are included in the Linux kernel. This will involve primarily hardening semantic patches that have been developed previously, and putting them in the form used in the semantic patches Linux kernel. There is ample opportunity to contribute patches to Linux source code as part of the semantic patch hardening process. | 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: |
''Mentor:'' [http://kernelnewbies.org/JuliaLawall Julia Lawall] | 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: |
== Linux-Kernel RCU == | 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 39: | Line 40: |
Potential projects include: | 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 41: | Line 42: |
1. Automatically Locate RCU Abuses 1. Inline __rcu_read_lock() __ 1. Add kmem_cache_free_rcu() 1. Validate RCU Algorithms 1. Automate Testing of RCU CPU Stall Warnings 1. Port RCU's KVM Scripts 1. Miscellaneous Fixes to RCU |
''Mentors:'': [:Daniel_Vetter:Daniel Vetter], [:SeanPaul:Sean Paul] |
Line 49: | Line 44: |
For more details on each project, please see [http://kernelnewbies.org/OPWIntro-RCU this page]. | == attribute documentation == ''Mentor:'': [:JuliaLawall:Julia Lawall] |
Line 51: | Line 47: |
''Mentor:'' Paul E. McKenney < paulmck@linux.vnet.ibm.com > == ath5k == [http://wireless.kernel.org/en/users/Drivers/ath5k Ath5k] is a completely FOSS wireless driver for Atheros based wireless chipset versions AR5xxx in the Linux Kernel. The hardware is old but the driver is still heavily used on academia/research and on various modern applications (e.g. 802.11p). Some time ago Adrian Chadd released code on AR5513 (the Atheros HAL -Hardware Access Layer- for that chipset), it's a chipset able to do 802.11a/b/g with a smart antenna/dual PHY design. The goal of this project is to port this code on ath5k and add support for AR5513. In the process you'll get familiar with the low level parts of wireless cards, the inner workings of a device driver, the related subsystems and the challenges we face when playing with hardware. An additional potential project is to implement 802.11 power saving modes for existing devices, enabling more efficient use in battery-powered stations such as laptops. Some preliminary patches have been already posted, but they need cleanup, functional changes, and validation. The interested intern would study the 802.11 specification, relevant parts of mac80211, the provisional patches, and possibly other related drivers such as ath9k to create a working, upstreamable implementation of power saving. ''Mentors:'' [http://kernelnewbies.org/NickKossifidis Nick Kossifidis], [http://kernelnewbies.org/AdrianChadd Adrian Chadd], [http://kernelnewbies.org/BobCopeland Bob Copeland] |
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 64: | Line 50: |
''Mentor:'': [:pablo:Pablo Neira Ayuso] | |
Line 65: | Line 52: |
[http://www.netfilter.org/projects/nftables/ nftables] is a new firewalling framework available since the Linux kernel 3.13. It includes new userspace libraries and utilities that aim to replace the popular [http://www.netfilter.org/projects/iptables/ {ip,ip6,arp,eb}tables] utilities. | 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 67: | Line 54: |
The goal of this internship is to help to improve nftables, this includes: | If you are interested in this project please consider solving any of the following tasks: |
Line 69: | Line 56: |
1. chase bugs and fix them. We already have a good bunch in the [http://bugzilla.netfilter.org Netfilter's bugzilla website]. 1. implement an automated testing infrastructure for nftables that would help to catch regressions. 1. help us implement some of the missing [http://people.netfilter.org/pablo/map-pending-work.txt features]. |
* 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 73: | Line 60: |
Please, read the [http://wiki.nftables.org nftables HOWTO] to get familiarized with the new software. | For more information on nftables, please check: http://wiki.nftables.org |
Line 75: | Line 62: |
''Mentor:'' [http://kernelnewbies.org/Pablo Pablo Neira Ayuso] | == IIO driver == ''Mentors:'': [:DanielBaluta:Daniel Baluta] & [:AlisonSchofield:Alison Schofield] |
Line 77: | Line 65: |
== Kernel tinification (for next round) == | 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 79: | Line 67: |
Over time, the Linux kernel has grown far more featureful, but it has also grown significantly larger, even with all the optional features turned off. I'd like to reverse that trend, making the kernel much smaller, to enable ridiculously small embedded applications and other fun uses. | 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 81: | Line 69: |
In this project, you'll start from "make allnoconfig", and then try to shrink the kernel even further. You'll learn how to work with the kernel configuration system, Kconfig, and use scripts/bloat-o-meter to measure the size impact of a change. | We will provide you the hardware setup necessary to test the driver. If you are interested in this project please solve ["IIO tasks"]. |
Line 83: | Line 71: |
This is a highly incremental project: each feature you make optional or kernel component you shrink will mostly stand alone, and you can develop and submit each change independently. | '''For IIO patches, be sure to send them to linux-iio@vger.kernel.org''' |
Line 85: | Line 73: |
Some of these tinification goals will work well during the application period; others will require a substantial time investment, and will primarily make sense during the full internship. | == Project == ''Mentor:'': [:WikiName:Mentor names] |
Line 87: | Line 76: |
Before working on any of these, especially during the application period, you should send a quick note to the OPW kernel mailing list to coordinate, and avoid duplicated effort. All patches submitted for this project should include the output of "scripts/bloat-o-meter", run on the old and new "vmlinux" binaries. That will tell you exactly how much space the change saved. Almost all new Kconfig options added for this project should depend on CONFIG_EMBEDDED. Goals that will work either during the internship or during the application period: * Make individual syscalls or groups of syscalls optional. See notes below for syscalls that can't currently be compiled out. * Turn contig_page_data into .bss since it needs so little of itself initialized. * Configure out writing time to the hardware clock (and in the process, compile out RTC_LIB) * Compile out arch/x86/boot/early_serial_console * Remove runtime extable sorting logic if CONFIG_BUILDTIME_EXTABLE_SORT * Rip out the rest of kernel/smpboot.c if !CONFIG_SMP Goals that should wait until a full internship: * Make ptrace optional. * Modify GCC's "section" attribute to support specifying different sections for initialized (.data) and uninitialized (.bss) data, and use that to put uninitialized __initdata or per-CPU data into .bss. (This will require very detailed exploration of the toolchain, Linux's linker scripts, and similar.) * Rip out more of the per-CPU infrastructure when CONFIG_SMP=n * Support configuring out kswapd. * Make the kernel's entire random number infrastructure optional. * Compile out mm/vmstat (need to stub out bits that obtain statistics used by other bits of the kernel) List of syscalls that the kernel doesn't currently support compiling out: sys_access sys_adjtimex sys_alarm sys_brk sys_capget sys_capset sys_chdir sys_chmod sys_chown sys_chroot sys_clock_adjtime sys_clock_getres sys_clock_gettime sys_clock_nanosleep sys_clock_settime sys_clone sys_close sys_creat sys_dup sys_dup2 sys_dup3 sys_execve sys_exit sys_exit_group sys_faccessat sys_fadvise64 sys_fadvise64_64 sys_fallocate sys_fchdir sys_fchmod sys_fchmodat sys_fchown sys_fchownat sys_fcntl sys_fcntl64 sys_fdatasync sys_fgetxattr sys_flistxattr sys_fork sys_fremovexattr sys_fsetxattr sys_fstat sys_fstat64 sys_fstatat64 sys_fstatfs sys_fstatfs64 sys_fsync sys_ftruncate sys_ftruncate64 sys_futimesat sys_getcpu sys_getcwd sys_getdents sys_getdents64 sys_getegid sys_geteuid sys_getgid sys_getgroups sys_gethostname sys_getitimer sys_getpgid sys_getpgrp sys_getpid sys_getppid sys_getpriority sys_getresgid sys_getresuid sys_getrlimit sys_getrusage sys_getsid sys_gettid sys_gettimeofday sys_getuid sys_getxattr sys_ioctl sys_ioperm sys_kill sys_lchown sys_lgetxattr sys_link sys_linkat sys_listxattr sys_llistxattr sys_llseek sys_lremovexattr sys_lseek sys_lsetxattr sys_lstat sys_lstat64 sys_mkdir sys_mkdirat sys_mknod sys_mknodat sys_mmap_pgoff sys_mount sys_munmap sys_nanosleep sys_newfstat sys_newfstatat sys_newlstat sys_newstat sys_newuname sys_ni_syscall sys_nice sys_old_getrlimit sys_old_mmap sys_old_readdir sys_old_select sys_oldumount sys_olduname sys_open sys_openat sys_pause sys_personality sys_pipe sys_pipe2 sys_pivot_root sys_poll sys_ppoll sys_prctl sys_pread64 sys_preadv sys_prlimit64 sys_pselect6 sys_ptrace sys_pwrite64 sys_pwritev sys_read sys_readahead sys_readlink sys_readlinkat sys_readv sys_reboot sys_removexattr sys_rename sys_renameat sys_renameat2 sys_restart_syscall sys_rmdir sys_rt_sigaction sys_rt_sigpending sys_rt_sigprocmask sys_rt_sigqueueinfo sys_rt_sigsuspend sys_rt_sigtimedwait sys_rt_tgsigqueueinfo sys_sched_get_priority_max sys_sched_get_priority_min sys_sched_getaffinity sys_sched_getattr sys_sched_getparam sys_sched_getscheduler sys_sched_rr_get_interval sys_sched_setaffinity sys_sched_setattr sys_sched_setparam sys_sched_setscheduler sys_sched_yield sys_select sys_sendfile sys_sendfile64 sys_set_tid_address sys_setdomainname sys_setfsgid sys_setfsuid sys_setgid sys_setgroups sys_sethostname sys_setitimer sys_setns sys_setpgid sys_setpriority sys_setregid sys_setresgid sys_setresuid sys_setreuid sys_setrlimit sys_setsid sys_settimeofday sys_setuid sys_setxattr sys_sgetmask sys_sigaction sys_sigaltstack sys_signal sys_sigpending sys_sigprocmask sys_sigsuspend sys_splice sys_ssetmask sys_stat sys_stat64 sys_statfs sys_statfs64 sys_stime sys_symlink sys_symlinkat sys_sync sys_sync_file_range sys_sync_file_range2 sys_syncfs sys_sysctl sys_sysinfo sys_tee sys_tgkill sys_time sys_timer_create sys_timer_delete sys_timer_getoverrun sys_timer_gettime sys_timer_settime sys_times sys_tkill sys_truncate sys_truncate64 sys_umask sys_umount sys_uname sys_unlink sys_unlinkat sys_unshare sys_ustat sys_utime sys_utimensat sys_utimes sys_vfork sys_vhangup sys_vmsplice sys_wait4 sys_waitid sys_waitpid sys_write sys_writev (Note to mentors and prospective applicants: Josh plans to present this list at Linux Kernel Summit, and may add, remove, or edit items on this list based on feedback obtained there.) ''Mentor:'': Josh Triplett |
Brief project description. |
Line 121: | Line 81: |
* 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 March 19th. * Use our [:OPWfirstpatch:tutorial] to send in your first kernel patch by March 19th. == Creative Commons Photo Credits == [http://tux.crystalxp.net/ Pink Tux] |
* 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 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 [https://www.gnome.org/outreachy/ Outreachy homepage] for an introduction to the program.
The application period for Round 15 will start on September 7, 2017. 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 [: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 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
How to apply
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.
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 23.
Use our [:Outreachyfirstpatch: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 [: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 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.
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:Daniel Vetter], [:SeanPaul:Sean Paul]
attribute documentation
Mentor:: [:JuliaLawall: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: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
IIO driver
Mentors:: [:DanielBaluta:Daniel Baluta] & [:AlisonSchofield: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:: [: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 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.