Taking the Eudyptula Challenge
LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing
Linux kernel development is tricky to learn. Though there are lots of resources available covering many of the procedural and technical facets of kernel development as well as a mailing list for kernel newbies, it can still be difficult to figure out how to get started. So some kind of "challenge" may be just what the penguin ordered: a series of increasingly difficult, focused tasks targeted at kernel development. As it turns out, the Eudyptula Challenge—which has been attracting potential kernel hackers since February—provides exactly that.
As the challenge web page indicates, it was inspired by the Matasano Crypto Challenge (which, sadly, appears to be severely backlogged and not responding to requests to join). The name of the challenge comes from the genus of the Little Penguin (Eudyptula minor) and the pseudonymous person (people?) behind the challenge goes by "Little Penguin" (or "Little" for short).
Getting started
Signing up for the challenge is easy; just send an email to little at eudyptula-challenge.org . In fact, it is so easy that more than 4700 people have done so, according to Little, which is many more than were expected. The first message one receives establishes the "rules" of the challenge as well as assigning an ID used in all of the subsequent email correspondence with Little. After that, the first task of the challenge is sent.
All of the interaction takes place via email, just like Linux kernel development. For the most part, the tasks just require locally building, changing, and running recent kernels. There are a few tasks where participants will need to interact with the wider kernel community, however. A recent rash of cleanup patches in the staging tree may quite possibly be related to the challenge.
I started the challenge on March 3 after seeing a Google+ post about it. I have done some kernel programming along the way. I did a couple of minor patches a few years back and some more extensive hacking many moons ago—back in the 2.4 days—and some before that as well. So I was by no means a complete novice. I have a good background in C programming and try to keep up with the Kernel page of a certain weekly publication. While all of that was helpful, it still was quite a bit of work to complete the twenty tasks that make up the challenge. It took a fair amount of effort, but it was also a lot of fun—and I learned a ton in the process.
While I won't be revealing the details on any of the tasks (and Little tells me that some have been tweaked over time and may be different than the ones I did), I can describe the general nature and subject areas for the tasks. It should be no surprise that the first task is a kernel-style "hello world" of sorts. From there, things get progressively harder, in general, and the final task was fairly seriously ... well ... challenging.
Building both mainline and linux-next kernels figures into most of the tasks. Many of the tasks also require using the assigned ID in some way. Not surprisingly, kernel modules figure prominently in many of the tasks. As you progress through the early tasks, you will learn about creating devices, debugfs, and sysfs. In addition, kernel coding style, checkpatch.pl , sparse , and how to submit patches are all featured.
In the later tasks, things like locking, kernel data structures, different kinds of memory allocation, kernel threads and wait queues, as well as a few big subsystems, such as networking and filesystems, are encountered. It is, in some sense, a grand tour of the kernel and how to write code for it. Which is not to say that it covers everything—that might require a tad more than twenty tasks—but it does get you into lots of different kernel areas. There are even plans to add more tasks once there is a good chunk of people (say 40–50) who have completed the challenge, Little said. At the current rate, that will be several months out.
Participant progress
The challenge is not a race of any kind—unless, perhaps, you are trying to complete it so you can write an article about it—but at least twenty people have completed it in the three months since it was announced. Given the nature of the challenge, it's a bit difficult to pin down how many are actually actively still working on it, but the statistics on how many have completed certain tasks can give a bit of a picture.
Roughly three-quarters of the 4700 who have signed up have never completed the first task. Presumably many of those were just curious about the challenge without any real intention to participate. But it is entirely possible that some of those folks are still working on that first task and may eventually work their way through the whole thing. On the other hand, though, that means that around 1200 folks have gotten a module built and loaded into their kernel, which is quite an accomplishment for those participants—and for the challenge.
The bulk of the participants are still working on tasks up through number six and there are less than 100 working on tasks ten and higher. Some of that may be due to some tasks' queues being slower than others. There is manual review that needs to be done for each task, and some tasks take longer than others to review. It might not have been designed that way, but that sort of simulates the review process for kernel patches, which features unknown wait times. Longer queues may also be caused by participants having to try several times on certain tasks, while other tasks are commonly "solved" the first time.
Often the tasks are described loosely enough that there are several to many different ways to complete them. Some solutions are better than others, of course, and Little will patiently point participants in the right direction when they choose incorrectly. I found that the more open-ended the task, the more difficult it was for me—not to complete it so much as to choose what to work on. That may just be a character flaw on my part, however. The final task was also a significant jump in difficulty as well, I thought.
Documentation
One thing that participants are likely to notice is how scattered kernel documentation is. There is, of course, the Documentation directory, but it doesn't cover everything and was actually of fairly limited use to me during the challenge. Google is generally helpful, but there is a huge amount of information out there in various forums, mailing lists, blog posts, weekly news magazines, and so on, some of which is good and useful, some of which is old and possibly semi-useful, and some of which is just plain misleading or wrong. It's not clear what to do about that problem, but it is something that participants (and others learning about the kernel) will encounter.
Based on an April 24 status report that Little sent out, there have been some growing pains. It's clear that the challenge is far more popular than was expected. That has led to longer wait times and some misbehavior from the " convoluted shell scripts that are slow to anger and impossible to debug " (as they are described on the web page). There have also been problems with folks expecting a tutorial, rather than a challenge that will take some real work to complete. Lastly, Little mentioned some people trying to crash or crack the scripts, which is kind of sad, but probably not unexpected.
In any case, the Eudyptula Challenge is a lot of fun, which makes it a great way to learn about kernel development. While it is targeted at relative newbies to the kernel, it wouldn't shock me if even seasoned kernel hackers learned a thing or two along the way. It is self-paced, so you can put in as much or as little time as you wish. There is no pressure (unless self-imposed) to complete anything by any particular deadline—the kernel will still be there in a week or a month or a year. Give the challenge a whirl ... it will be time well spent.