How do i get started?

[Peter Teoh]

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