Thank you very much...thank you for the comments....I will do a little bit of each when the opportunities comes....yes, i think there are lots of things to do, but assuming i will live only till tomorrow....i will choose to do those deemed most crucial ones :-). some of the ideas below are new to me, thanks! On Sun, Mar 16, 2008 at 11:14 AM, Jesper Juhl <jesper.juhl at gmail.com> wrote: > 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 > > > _______________________________________________ > devel mailing list > devel at linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > -- Regards, Peter Teoh
