How do i get started?

Jesper Juhl jesper.juhl at
Sun Mar 16 03:14:10 UTC 2008

On 15/03/2008, Travis Athougies <iammisc at> wrote:
> Just wanted to know how I should get started.

There are lots of ways to contribute. All depend on how much effort
you are willing to put towards it and what your skill level (and area)

A few suggestions;

Take a look at the Kernel Janitors TODO list:
There are many good tasks on that list that need doing. Some easy,
some hard. You should be able to find something that matches what you
are able to do.

Sign up for the Coverity scan results for the Linux Kernel. See
The static analysis of the Linux Kernel that Coverity does locates
many interresting bugs. Fixing them requires various levels of skill
and knowledge of the kernel code in question, but you are bound to
find some that you are able to fix.

Do some 'randconfig' builds of the kernel and try to fix the warnings
and errors that result.
Here's the script I personally use to run a bunch of randconfig builds
(and save the .config and output so it is easy to re-create a given
config) :

for i in $(seq ${1} ${2}); do
        echo "Running distclean"
        make distclean > /dev/null 2>&1
        while true; do
                echo "Running randconfig"
                make randconfig  > /dev/null 2>&1
                grep -q "CONFIG_EXPERIMENTAL=y" .config
                if [ $? -eq 0 ]; then
                        echo "Whoops, this turned out to be an
experimental config - skipping"
                grep -q "CONFIG_BROKEN_ON_SMP=y" .config
                if [ $? -eq 0 ]; then
                        echo "Whoops, this turned out to be a broken
on smp config - skipping"
                echo "Config looks good to build"
        echo "Config OK to build, saving a copy of the config as config.${i}"
        cp .config config.${i}
        echo "Running make. Saving output in build.log.${i}"
        nice make -j 3 > build.log.${i} 2>&1
        echo "Build ${i} done."
        sleep 3

Read 'Documentation/feature-removal-schedule.txt' and look for stuff
that's long overdue. Then submit patches to fix whatever the issue is.

Run the kernel source through the 'sparse' tool (see
.Documentation/sparse.txt). Fix any issues you encounter.

Read through documentation and config help messages. Fix spelling
errors, incorrect links to files, incorrect information etc.

Think of common and easy to fix coding mistakes. Write scripts to find
them. Then fix them.
For example, many of my recent patches to clean up duplicate includes
were based on a simple script that would grep all source files for
lines starting with "#include", sort them and 'uniq -c' them, then I'd
look through the result and remove any duplicates that were just
unneeded. Another example would be my patches that simplified pointer
derefs. I wrote a small script to detect multiple occurences of stuff
like foo->bar->baz in a file, then I'd write patches that changed that
into a single foobar = foo->bar->baz; then used 'foobar' for the
remaining locations.  Yet another example would be a script I wrote
that found locations where we did something like "if (pointer)" or "if
(pointer != NULL)" etc, followed by a call to kfree/kvfree of
'pointer' - that's pointless since kfree/kvfree already do a null
check, so I'd then submit patches to clean out the redundant test.
There are lots of oppertunities for writing simple "find a minor
problem" scripts like that and cleaning something up.

Try building the kernel on various platforms, with various compilers
(including non-gcc compilers). That often finds new and interresting
problem spots. Some platform/compiler combinations spot problems that
the common ones do not.

There are lots of ways to get started contributing to the kernel. You
just need to dive in :-)

Jesper Juhl <jesper.juhl at>
Don't top-post
Plain text mails only, please

More information about the devel mailing list