[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081001084825.GA25009@elte.hu>
Date: Wed, 1 Oct 2008 10:48:25 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Steven Noonan <steven@...inklabs.net>
Cc: linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH -tip] drivers/serial/8250.c: 'i' may be used
uninitialized
* Steven Noonan <steven@...inklabs.net> wrote:
> I was kind of worried about being exceedingly verbose, but I
> understand your point perfectly. I'm going to resend the patch with an
> appropriately verbose comment.
>
> As always, I appreciate the criticism. Thank you! :)
I have yet to meet a too verbose commit log, and i've seen many - so
there's basically no way you can stretch. Our problem 99% of the time is
that commit logs are either not verbose at all, or are structured in a
way that makes it hard to interpret them.
If you think a change is too verbose, you could start using the
'Impact:' line convention we recently started using in the x86 tree.
Something like:
serial, 8250.c: fix warning: 'i' may be used uninitialized
Impact: cleanup, fix bogus gcc warning
serial_unlink_irq_chain() does not initialize iterator 'i', and that is
correct logically because it is always initialized due to XYZ. Gcc does
not realize this connection and emits a false warning. Annotate it with
uninitialized_var().
Signed-off-by: Steven Noonan <steven@...inklabs.net>
Other good 'Impact:' tags are:
Impact: fix boot crash
Impact: style cleanup
Impact: documentation fix
it's a "see impact at a glance" kind of thing. Maintainers will still
read the rest and the code as well, but the thought process is much
smoother: the maintainer can concentrate on "does what the patch does
meet the expectation spelled out in the changelog", instead of spending
time on "what does this patch do" thinking.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists