2008/5/22 Al Viro <viro@zeniv.linux.org.uk>:
quoted text
> 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.
>
>> - 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.
>
>> 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.
>

Thanks a lot for your comments Al.
I'll try to incorporate most of it in the next revision of the document.

-- 
Jesper Juhl <jesper.juhl@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
--
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/