In this post, I'll make a brief description of the project, its purpose, and the tasks required.

First, why work on the Linux Kernel?

The Linux Kernel is everywhere; the cloud infrastructure that serves the websites you visit, Android phones, computers, embedded systems, and so, the modern world depends on it! The Linux Kernel development is very active, and many software engineers are part of it. For example, in the last Kernel 5.4 release, at least 1804 programmers contributed with 14000 changesets. These are amazing statistics for an open-source project and might sound intimidating, but the more you get involved, the more opportunities you'll find in its development.

Now let's talk litmus tests.

Concurrency has always being a complicated topic, and sometimes CPU architectures differ greatly in their execution models and add to these issues that the Linux Kernel supports more than 30 CPU architectures. This is why the LKMM (Linux Kernel Memory Model) was proposed as a way to simulate executions in the Linux Kernel through litmus tests.

It's a tool that allows you to simulate the execution of concurrent code and determine if it can lead to undesired results or bugs by checking specific conditions to help you understand how the memory model outcomes in different architectures.

If you can't think how buggy concurrent code can go wrong, check this video about concurrency bugs on GPUs:

Now let's briefly check how litmus tests look like; this is how the most basic Message Passing (MP) litmus test:

P0(int *x, int *y)

{

WRITE_ONCE(*x, 1);

WRITE_ONCE(*y, 1);

}

P1(int *x, int *y)

{

int r0;

int r1;

r0 = READ_ONCE(*y);

r1 = READ_ONCE(*x);

}

exists (1:r0=1 /\ 1:r1=0)

In this test we can observe that a processor #0 (P0) writes values on the shared variables x and y and the processor #1 (P1) reads them, then we check a "buggy" condition: P1 observes the write to y (the last one) but not x. Contrary to common sense, there might be states where P1 can observe both writes, one of them or none as we are simulating the execution on a relaxed memory model, where the instructions might get executed in a different order than the intended by the programmer.

Source: Kernel panic by William Pina

Today I received the news "Congratulations on being accepted…", and I couldn't be more excited!

This journey began a couple of months ago after I read on Twitter about an organization called Outreachy, which promotes diversity in tech and accepts applicants from anywhere in the world for a paid internship to contribute to open source projects. It's also supported by some of the top companies in the tech world. It sounded too good to be true at first, and I had to read the Applicant Guide a couple of times before getting convinced I was eligible; I was! The projects couldn't be more amazing as I always wanted to contribute to Linux open-source projects. I applied and got accepted as an applicant.

Contributing to a Linux Kernel project

When I read the Linux Kernel projects, my first thoughts were how "hard" they all looked, but one project specially called my attention: "Develop a suite of litmus tests for Linux-kernel spinlocks and read-write locks." I always had something for everything low level, and I already did a small project about 16 and 32 bits CPUs and X86 assembly instructions. A project that would allow me a better understanding of the underneaths of concurrency in the Linux Kernel was something I needed.

The first part of applying to the Linux Kernel projects was about contributing with small patches to the staging drivers maintained by Greg Kroah-Hartman. These drivers contain code that doesn't meet the Kernel standards, so there are plenty of files that need to be reviewed, cleaned, refactored, and overall improved. Starting these contributions were a small project by itself. We had to compile and install the last release candidate of the (still under development) kernel 5.4, read technical lectures about the kernel drivers, get started with the tools we needed for the task, complete a contribution guide. The most important part was getting our contributions good enough to be accepted by Greg.

After days of reading code, fixing mistakes, improving my Git skills, and fixing even more errors, I got enough patches accepted for the next step and start with the specific tasks by contacting the mentors. These tasks finally seemed to be about the project topic, and more reading and activities ensued; the litmus tests, the LKMM, memory barriers, the ARM and PowerPC relaxed memory model, and the tools to simulate or test the memory model. Even if I felt a little overwhelmed by all this information at first, after some days, I started enjoying this part of the applicant process. I also got the tests working on an unused Raspberry Pi 3, so I could do some tests on an ARMv8 CPU.

Final Application

The mentor helped me solve my doubts or issues and asked me questions to test my (very recently acquired) knowledge. Fortunately, I did a good job, so I was invited to submit my final application, which would include information about my previous experience with open source projects and a timeline of my (possible) future activities as an intern. I completed this and waited while keeping in touch with my mentor as I continued testing and reading, and all the invested time finally paid off today!

My journey with Outreachy as an intern just started (soon actually), but my suggestions to new applicants would be:

• Read the Applicant Guide and make sure you are eligible, and you can commit to the process.
• Choose a project you are passionate about.
• Make sure you can dedicate enough time to send an excellent contribution to the project.
• Study everything you possibly can to understand the topic better, and when in doubt, ask mentors.