[ANSOL-geral] Why Contributing to the Linux Kernel is Easier Than You Think

André Isidoro Fernandes Esteves aife netvisao.pt
Segunda-Feira, 26 de Outubro de 2015 - 02:45:52 WET

Why Contributing to the Linux Kernel is Easier Than You Think

Monday, 12 January 2015 13:00    Konrad Zapałowicz    |Exclusive 98269

Konrad Zapalowicz presented at LinuxCon Europe in Dusseldorf, Germany in 
2014, about how to get started as a Linux kernel developer.

I gave a talk at LinuxCon Europe in Dusseldorf last year with the main 
goal being to show people how easy it is to start with Linux kernel 
development. Despite my fear that the audience might be too advanced and 
find this topic rather boring I received good feedback with several 
opinions that these kind of guidelines and advice are more than welcome. 
Now, since the room capacity was about 30 people, which is not really 
much, I have the impression that there are more folks out there who 
would enjoy this topic. Therefore I decided to form the presentation 
into a series of articles. (See the full presentation at 

These articles, similar to the talk, will be divided into three parts. 
In the first, not really technical article, I will explain that Linux 
kernel development is super easy especially for those who possess the 
right attitude. In the second part I'm going to show where to get 
inspiration and the best angles to approach Linux kernel development for 
newcomers. And in the third and last part, I will describe some of the 
things that I wish that I knew before I started.

4 Myths

For some reason there is a group of negative opinions or myths 
describing either Linux kernel programming itself or the effort required 
to become a Linux kernel developer. In particular these are:

Linux Kernel programming is hard and requires special skills.
Linux Kernel programming requires access to special hardware.
Linux Kernel programming is pointless because all of the drivers have 
already been written.
Linux Kernel programming is time consuming.
Let's put more detail into this way of thinking:

Myth #1: The Linux Kernel programming is hard and requires special skills.

This thinking comes from the fact that many people, especially without 
proper knowledge of the kernel internals tend to view the the whole 
project as one big blob of code, effectively an operating system itself. 
Now, we all know that writing the operating system is a damn hard job 
and requires deep understanding of quite a number of different topics. 
Usually this is not just a hobby ;) but something that you are well 
prepared for. Looking at the top-level Linux kernel developers does not 
help either because all of them have many years of experience and 
judging your own skills using them as a reference leads one to believe 
that special skills are in fact required.

Myth #2:  Linux Kernel programming requires access to a special hardware.

Jim Zemlin, who is the executive director of the Linux Foundation, said 
during his LinuxCon keynote that open source software is running on 80 
percent of electronic devices. The Linux kernel, as the biggest open 
source project ever, gets more than a huge bite of this cake. In fact 
this is the most portable software of this size ever created and it 
supports an insane number of different hardware configurations. With 
this in mind one might get the impression that working on the kernel is 
about running it on different kinds of devices and since the most 
popular are already supported a successful developer needs to have 
access to all sorts of odd hardware.

Myth #3: Linux Kernel programming is pointless because all of the 
drivers have already been written.

The very popular impression of Linux kernel programming is writing 
drivers for various kind of peripheral devices. This is in fact the way 
that many professional kernel hackers nowadays  have started their Linux 
carers. However, with the portability that the kernel offers it may seem 
that it is hard to find unsupported devices. Naturally we could look at 
the USB devices landscape as here we have the majority of peripherals, 
however most of those are either already supported or it is better to 
use the libusb and solve the problem from the user space, thus no kernel 

Myth #4: Linux Kernel programming is time consuming.

While reading the LKML or any other kernel-related mailing list such as 
the driverdevel list it is easy to notice that the number of patches 
sent weekly is significant. For instance the work on the comedi drivers 
generates sets with many patches in it. It clearly shows that someone is 
working really hard out there and the comedi is not alone as an example. 
For people for whom kernel development is going to be a hobby, not a 
daily job, this might be off-putting as they could feel that they just 
cannot keep up the pace with that kind of speed of development.

The Facts

These either alone or accumulated can draw a solid, thick line between 
trying Linux kernel development and letting it go. This is especially 
true for the less experienced individuals who therefore may fear trying, 
however the truth is that, to quote Dante, “the devil is not as black as 
he is painted.” All of these myths can be taken down so let's do it one 
by one:

Fact:  Linux Kernel programming is fairly easy.

One can view the kernel code as a single blob with rather high 
complexity, however this blob is highly modularized. Yes, some of the 
modules are really hardcore (like scheduler), however there are areas of 
less complexity and the truth is that in order to do very simple 
maintenance tasks the required skill is a decent knowledge of C.

Not everyone has to redesign kernel core modules, there is plenty of 
other work that needs to be done. For example, the very popular newbie 
task is to improve the code quality by fixing either the code style 
issues or compiler warnings.

Fact: Special hardware is not required.

Well, the old x86 is still good enough to do some parts of the work and 
since this architecture is still quite popular I would say that it is 
more than enough for most people. Those who seek more can buy one of the 
cheap ARM-based boards such as PandaBoard, BeagleBone or RaspberryPi.

Fact: It is not pointless, there is still work to be done.

The first thing to know is that the Linux kernel is not only about the 
drivers but also the core code which needs to be taken care of. Second 
there is still a vast amount of drivers to be completed and help in this 
area is more than appreciated.

Fact: It does not have to be time consuming.

Whoever works on the kernel allocates as much time as he or she wants. 
The people who do it out of passion, aside from their daily duties, use 
a few evenings a week and they still contribute. I started contributing 
during the period where I run every second day (evening), I still did a 
complete renovation of part of my apartment, I went for holidays, and I 
watched almost every game during the World Cup 2014 and World Volleyball 
Championship 2014. There was not much time left for kernel stuff and 
still I succeeded in sending a few patches.

The important thing to remember is that unless you are paid for it there 
is no pressure and no hurry so take it easy and do as much as you can.

A New Mindset

In this first installment of a series aimed at encouraging people to do 
kernel programming. I introduced a complete change of mindset by 
explaining that what might have seemed hard is in fact fairly easy to 
do. Just remember that:

Linux kernel programming is fairly easy.
It is not required to have access to special hardware.
There is still a lot of work to be done.
You can allocate as much time as you want and as you can.
Armed with this knowledge we are ready for the next part which will give 
insight into what could be your starting point in Linux kernel development.


Three Ways for Beginners to Contribute to the Linux Kernel

Wednesday, 21 January 2015 16:04    Konrad Zapałowicz    |Exclusive 1239

I immediately saw that I need to be proactive because no one will do any 
kind of work for me... I decided to be a one instead of a zero and find 
a couple of starting points for a newbie (wannabe) Linux kernel 
contributor. Image source: Pixabay, creative commons.

The learning curve to becoming a Linux kernel developer is pretty steep 
and choosing the right direction might be somewhat difficult (but not as 
hard as you think - see my previous article.) However, I have some ideas 
on how to start this beautiful journey. I hope that these guidelines 
will be useful for someone.

When I finished the Eudyptula Challenge, a series of programming 
exercises that teaches you how to contribute to the Linux kernel, I got 
involved in a discussion with *little* who is the penguin that runs the 
challenge. He asked me if I would like to contribute and when I 
confirmed, he asked me if I have any idea what I would like to do in the 

I answered that given my current level of knowledge the best for me 
would be to work with one of the maintainers who could tell me what 
shall be done and later review my work so that I could learn and do 
something useful at the same time. Can you guess the answer? It was:

"No maintainer has that time, sorry."

In this particular moment I understood what my attitude should be. I 
immediately saw that I need to be proactive because no one will do any 
kind of work for me. This reminded me of a quote from one of the hacker 
movies that I enjoyed as a teenager; it fits:

“This business is all about bits. It is up to us if we are one or zero.”

I decided to show the "1" attitude and find a couple of starting points 
for a newbie (wannabe) Linux kernel contributor.

1. Improve the code quality

This is the easiest type of task and as such it has a very good ratio of 
difficulty to the learning value. In essence it is about either making 
sure that the code follows the coding styleor eliminating the static 
code checker errors and warnings. In general the code is in pretty good 
shape because of the policy of not allowing patches which contain such 
flaws. However there are a few (enough work for everyone) weak spots 
where things should be improved.

The biggest advantage of this kind of assignment is that it allows you 
to learn a lot. In particular it teaches the proper coding style, then 
the various areas of the kernel code, and last but not least it makes 
you a better programmer with the experience that you get.

So now, let’s see how to work on the coding style and on the static code 
checker complaints.

Apply the coding style

There is a tool called *checkpatch.pl* which resides in the *scripts* 
directory of the kernel repository. This very clever script checks 
either the patches or files for issues in the coding style. 
Additionally, if the input file is a patch, it verifies if it conforms 
to the patch format.

The usage is very simple as it checks the input files, which by default 
are understood to be patches (the product of git format-patch.) There is 
**-f** option which tells the script that the input is a regular file so 
it will not check the format of the patch.

% scripts/checkpatch.pl ../patches/*patch

% scripts/checkpatch.pl -f drivers/tty/serial/jsm/*c

This is the sample output for one of the patches that I prepared. As you 
can see I was careless enough to sneak one coding style issue.

konrad in linux-mainline on jsm-work % scripts/checkpatch.pl 

WARNING: Unnecessary space before function pointer arguments

#28: FILE: drivers/tty/serial/jsm/jsm.h:123:

+       void (*clear_break) (struct jsm_channel *ch);

total: 0 errors, 1 warnings, 32 lines checked

has style problems, please review.

If any of these errors are false positives, please report

them to the maintainer, see CHECKPATCH in MAINTAINERS.

konrad in linux-mainline on jsm-work %

Static check the code

The next step, after improving the style, is to actually fix the broken 
code. The Linux kernel build system uses the sparse static code analyzer 
which, when enabled, runs over every file that is compiled and if there 
is anything wrong with it, reports it. It’s as simple as that.>

The prerequisite however is to install it which shouldn't be an issue 
for a modern Linux distribution. On Ubuntu it is enough to type in the 

% sudo apt-get install sparse
Moreover the releases can be downloaded from kernel.org and installed 
using the *make & make install* combo. The usage is very simple as there 
is a *make* option for it.

% make C=1
It will run static checker over every file that is being compiled in. 
This is the example output of running sparse over the dgap driver from 
the staging area. The code is in a pretty good state as there is only 
one warning reported.

konrad in linux-mainline (jsm-work) % make C=1 M=drivers/staging/dgap

  LD      drivers/staging/dgap/built-in.o

  CHECK   drivers/staging/dgap/dgap.c

drivers/staging/dgap/dgap.c:365:25: warning: too long initializer-string 
for array of char

  CC [M]  drivers/staging/dgap/dgap.o

  Building modules, stage 2.

  MODPOST 1 modules

  CC      drivers/staging/dgap/dgap.mod.o

  LD [M]  drivers/staging/dgap/dgap.ko

konrad in linux-mainline (jsm-work) %

2. Read the TODOs

Naturally, after a while of improving the code quality it is good to 
move on and seek different kinds of assignments. The source tree 
contains a number of TODO files which, to some extent, contain 
descriptions of work that shall be done. This is a starting point and a 
source of inspiration for anyone willing to do something in the kernel 
without a real idea on where to start. This was my way of getting 
involved in the development of *staging/dgnc* and later the *jsm* driver.

At the time of writing there are 53 TODO files in the kernel source 
tree. I figured out that the best way to browse them would be to merge 
the contents of each into one big text file for easier reading. I also 
wanted to know how long ago the TODO file had been updated. This is to 
check how accurate (or innacurate) the information might be. As a result 
I developed a terrible bash one liner which gave me what I wanted, here 
it is:

% echo "" > /tmp/todolist-kernel.txt; count=0; for entry in `find . 
-name "*TODO*"`; do echo $count". "$entry`git log --pretty=format:" Last 
edited %ar" $entry | head -1` >> /tmp/todolist-kernel.txt; echo "" >> 
/tmp/todolist-kernel.txt; sed 's/^/        /' $entry >> 
/tmp/todolist-kernel.txt; echo "" >> /tmp/todolist-kernel.txt; 
((count=$count+1)); done

It takes a while to execute but at the end all the information is ready 
for checking out in the /tmp/todolist-kernel.txt file. It might be hard 
to browse as it contains around 1.2k lines however it gets better with 
Vim and the foldmethod set to *indent*. Nevertheless, choosing the area 
of interest is a time consuming process so do not rush, read it 
carefully and make your choice.

I have been told that the information in the TODOs, at least in the 
staging area, should be accurate. However for example, for the *dgnc* 
driver it was not the case as some of the bullet points have already 
been addressed. I assume that this might be the case for a few other 
TODOs as well.

In my case I found this to be good for me because I had a chance (been 
forced to) to learn the code and understand how it works to be able to 
sort out what is done and what is not. So in general this is a good 
experience unless the TODO is painfully old. In this case everything is 
possible including the driver being obsolete and/or abandoned for good.

As for me I focused on the driver for which I could understand the 
bullet points from the TODO. I did not really want to be stuck in some 
kind of really difficult development. I believe that this is very good 
approach for newcomers into the Linux kernel development and in general 
because having a chance to actually accomplish something is very 
important for self confidence. So if you do not know much about Linux 
kernel programming I recommend my approach.

The drivers/staging area

I mentioned the *staging* area a few times so far. Now it is high time 
to elaborate more on what it is. So basically the drivers/staging area 
is a home for not yet officially supported drivers. The whole area is 
supported by Greg KH, the Linux DriverProject is behind it and people 
involved communicate on thedriverdev-develmailing list.

The code in staging does not meet the quality standards and the job is 
to make it good enough to be promoted as a 'real' kernel driver. This 
makes it a perfect place to start from especially when combined with the 
information from TODOs.

It is important to know that there is a significant amount of people 
working in this area nowadays. So it is good to follow the mailing list 
just to get the gist of what people are working on. It would be 
unfortunate to learn, after sending the patch, that someone has made 
this change like a week ago or something.

3. Fix a kernel bug

As any other software project the kernel has bugs. It can be either a 
direct crash or just a glitch reported in the bug tracking system. 
Regardless of what it is, fixing it is a great, challenging adventure as 
fixing bugs is more advanced than improving the code quality.

  Kernel OOPS

The kernel OOPS is a crash and it usually does not happen, nevertheless 
once in a

while it can be seen. Debugging such an issue is advanced stuff however 
it is a great learning experience. My best kernel patch so far is the 
one liner I implemented for the crash that I had a few months ago.


Kernel bugs are tracked using Bugzilla. This is a good source of 
inspiration for the brave. :)


As you see there is many ways of contributing and still a lot of work to 
be done. In short you can:

* start in the drivers/staging area

* improve the code quality

* find inspiration in the TODOs

* fix an actual bug in the kernel.

And there is much more inspiration that you can find when you actually 


Mais informações acerca da lista Ansol-geral