[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
Events.LinuxFoundation.org.)
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
work.
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
kernel.
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
../patches/0001*patch
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
../patches/0001-serial-jsm-Remove-unnecessary-parameter-from-clear_b.patch
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
terminal:
% 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.
Bugzilla
Kernel bugs are tracked using Bugzilla. This is a good source of
inspiration for the brave. :)
Summary
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
start.
http://www.linux.com/news/software/linux-kernel/801601-4-myths-about-linux-kernel-programming-debunked
-------------------------
http://www.linux.com/news/software/linux-kernel/804403-three-ways-for-beginners-to-contribute-to-the-linux-kernel
Mais informações acerca da lista Ansol-geral