On Thu, May 22, 2008 at 01:46:28AM +0200, Jesper Juhl wrote:

0.  Use your common sense.  No hard rules will ever replace that.

quoted text
> - Sign up with Coverity (http://www.coverity.com/) to get access to
> the results of their regular runs of Coverity Prevent against the
> kernel source. Their static analysis of the kernel source finds many
> bugs that need fixing. There is lots of good work there that needs
> doing.
> 
> Naturally there's also other work that can be done, like writing a
> driver for some, currently unsupported, hardware etc, but its probably
> best to get your feet wet with some bug fixing first.

If you are familiar with C, reading the kernel source (e.g. starting
at system call and going down from there) can be very useful; you will
need such skills anyway and you might actually find real bugs.

Asking the questions along the lines "code seems to assume that <this> never
happens; why can't it happen and what happens if it does?" is generally
welcome, assuming that question is more or less coherent.  "I do not
understand this code at all" will be less useful and "<this> is <expletives>
BROKEN!!!  I've found a major hole!!!" would better be right - which is not
impossible.  Use common sense; if you turn out to be wrong (which is also
quite possible), the size of crow you'll have to eat will be directly
proportional to the vehemence of the original posting.  That applies to all
of us - pretty much everyone had been there and probably will be there again
and again.  On the other hand, do not be surprised if the answer will be
"It's because...  Umm...  Oh, !@#!@#, looks like you've spotted a nasty hole".
It also happens and assuming that code is correct just because it is in the
tree is a bad mistake.  Newbies can and do find serious bugs and doing that
can earn one a lot of good will.

quoted text
> Try to stay away from doing pointless work, like just fixing up the
> coding style in a file, reformatting comments etc - it's not worth the
> effort and your patch is likely to be rejected. Fixing up incorrect
> comments to be correct, fixing up references to removed or renamed
> functions/arguments etc is, however, useful and worth doing.

Note that fixing up coding style in the code you are modifying is fine,
provided that coding style part does not obscure the real changes you
are making and the scale of coding style changes is not wildly out of
proportion.  Again, use the common sense - changing two lines in a function
is not a reason to reformat every file in directory while you are at it.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/