Round 10 projects are available [[OutreachyRound10|here]].  For each project, if you click on the proposer's name, you may find more information.

== ADXL377 Triple Axis Accelerometer IIO driver ==
''Mentor:'': [[OctavianPurdila|Octavian Purdila]], [[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 Analog Devices ADXL377 triple axis accelerometer using the Industrial I/O interface. In the first part of the project you will get familiar with the hardware and the IIO 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.

We will provide you the hardware setup necessary to test the driver. If you are applying to this project please make sure to solve the [[IIO_tasks|IIO tasks]].

== Staging driver cleanup ==
''Mentor:'': [[GregKH|Greg Kroah-Hartman]]

This project will dive into a few specific drivers in the staging tree, doing more than just basic code formatting cleanup.  The goal will be to help change the code to make it acceptable for merging into the "real" portion of the kernel.  If possible, hardware will be provided for the code being worked on.

== 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

== Ceph-related kernel code cleanup ==

''Mentor:'': [[AlexElder|Alex Elder]]

The Ceph project implements a scalable and fault-tolerant network based storage system.  Portions of Ceph reside in the Linux kernel, presenting either a block device or a file system interface backed by Ceph storage accessed over the network.

This project involves doing cleanup of the Ceph-related kernel code. The work will range from very easy fixes (like typo's and coding style) to more more substantive (refactoring functions and source files).  Typically this kind of work identifies bugs as well, and if so those will be fixed (or at least documented).

More information can be found [[OutreachyProjects/CephCleanup|here]].

== y2038 cleanup in drivers ==

''Mentor:'' [[ArndBergmann|Arnd Bergmann]]

The concept of 'time' in Linux is encoded in many different ways, but the most common one is based on the 'time_t' type that counts the number of seconds that have passed since Jan 1, 1970. This type is currently defined as 'long', which on 32-bit systems is a signed 32-bit number that will overflow on Jan 19 2038 and likely cause existing systems to stop working, see http://en.wikipedia.org/wiki/Year_2038_problem.

On 64-bit systems, the problem is solved for the most part because 'long' is a 64-bit number that will not overflow for billions of years, but there are some important missing pieces such as file systems that store time in 32-bit quantities on disk as well support for 32-bit user space binaries running on 64-bit kernels.

Solving this problem in general is a huge effort involving lots of changes in the kernel as well as in user space. This project focuses on the kernel side, can be nicely split up into many small subtasks and is a prerequisite for doing the user space changes. There are currently 2003 instances of 'time_t', 'struct timespec' and 'struct timeval' in the kernel, and we are going to replace all of them with other types.

Any isolated in-kernel uses of these types can be replaced with 'ktime_t' or 'struct timespec64'. For any interface to user space (typically an ioctl command or a system call) that passes a data structure based on these types, we have to keep the existing interface working and introduce an alternative interface that can be used by newly built user space programs.

[[y2038]] has a deeper introduction to the topic and will be updated with more detailed subtasks over time.