On 15/03/2008, Travis Athougies <iammisc at gmail.com> 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) is. A few suggestions; Take a look at the Kernel Janitors TODO list: http://kernelnewbies.org/KernelJanitors/Todo 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 http://scan.coverity.com/devfaq.html#account 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) : #!/bin/bash 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" continue fi 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" continue fi echo "Config looks good to build" break done 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 done 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 gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html
