On Mon, Oct 22, 2012 at 09:30:19AM +0200, Julia Lawall wrote:
> On Mon, 22 Oct 2012, Dan Carpenter wrote:
>
> > On Thu, Oct 18, 2012 at 03:07:55PM -0400, David Miller wrote:
> > > From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
> > > Date: Thu, 18 Oct 2012 21:01:46 +0800
> > >
> > > > On Thu, Oct 18, 2012 at 03:45:22PM +0300, Dan Carpenter wrote:
> > > >> On Wed, Oct 17, 2012 at 11:10:42AM +0200, Luis G.F wrote:
> > > >> > unsubscribe kernel-janitors
> > > >>
> > > >> Uh. Obviously this isn't the right way to unsubscribe. You have to
> > > >> send the email to majordomo@xxxxxxxxxxxxxxx and not to the list.
> > > >>
> > > >> But I do think we should maybe find another list for Fengguang's
> > > >> emails? It's sort of a lot higher traffic than before and sort of a
> > > >> different flavour.
> > > >
> > > > Agreed.. I'm afraid that my report titles are much more messy than
> > > > the normal emails and there could be a dozen of such reports per day.
> > > >
> > > > It may be more clean to send the build error/warning reports to a
> > > > standalone list.
> > > >
> > > >> I still will want to subscribe to the emails, but it would be better
> > > >> to use a different list. Apparently Dave Miller didn't like the
> > > >> idea of creating a special list for it because he didn't like the
> > > >> emails in the first place. But now I think everyone likes them a
> > > >> lot. It might be worth asking again.
> > > >
> > > > CC Dave Miller for possible new inputs.
> > >
> > > I find them super annoying, and these reports are extremely sub-optimal
> > > as is.
> > >
> > > The amount of time spent composing these reports could equally be spent
> > > condensing the error down to a small, self contained, set of text
> > > explaining the exact build failure and an initial root-cause estimate.
> > > And sending it to the correct maintainer's list.
> > >
> > > Heck, in the same amount of time, you could even implement the damn
> > > fix!
> > My understanding is the emails are composed automatically and take
> > zero time. If the error message has a very low false positive rate,
> > then the email is sent without any human interaction at all.
Yeah, that's the main idea. I'm trying to automating the email
reporting so as to achieve fast response time by avoiding human
introduced delays.
Build errors have been mostly automated, except when the system is not
so confident about the correctness of bisection.
Most gcc warnings cannot be false by nature and they are auto reported
too. The "possibly uninitialized variable" warnings have high false
rate, however considering that gcc warnings feels not good even if they
are false ones, I'm sending out private emails to the commit author to
make sure he is at least aware of the (possibly false) warning.
Some of the sparse/smatch/coccinelle warnings can be auto reported,
too. I'm now maintaining a list that are assumed to have low false
ratio (please correct me, thanks!):
______ smatch warnings ______
redundant null check
doing dma on the stack
______ cocci warnings ______
casting value returned by
alloc with no test
kzalloc should be used for
casting value returned by k[cmz]alloc to
returns NULL not ERR_PTR on failure
PTR_RET can be used
PTR_ERR applied after initialization to constant
ERR_CAST can be used with
inconsistent IS_ERR and PTR_ERR, PTR_ERR
of_node_put not needed after iterator
devm_request_mem_region followed by ioremap
Missing resource_size with
Suspicious code. resource_size is maybe missing with
nested lock+irqsave that reuses flags from line
application of sizeof to pointer
test of a variable/field address
opportunity for kmemdep
opportunity for kstrdep
opportunity for simple_open
comparing pointer to 0
Comparison to bool
Comparison of bool
Assignment of bool
______ sparse warnings ______
sparse: incorrect type in
sparse: cast from restricted
sparse: cast to restricted
degrades to integer
sparse: Using plain integer as NULL pointer
sparse: expression using sizeof bool
sparse: invalid assignment:
sparse: cast truncates bits from constant value
sparse: dubious: x | !y
sparse: cast removes address space of expression
sparse: mixing different enum types
sparse: non-ANSI function declaration of function
was not declared. Should it be static?
with external linkage has definition
However there are other lots of static check warnings that do need
manual check, which are now reported via private emails to Yuanhan and
me. If any one is interested in analyzing these possibly false
warnings and making bug fixing patches out of them, you'll be warmly
welcomed! :-)
> Perhaps what would be useful for the kernel janitors list is one message
> per day with one-line summaries of the affected files and the detected
> problems? The goal of sending it to kernel janitors was just to avoid
> duplicated work, and it seems like such summaries would do that just as
> well, without inducing so many messages?
Good idea. I can do the summary if the too many reports are a problem
for the list.
However it also means you'll not see many of the responses from the
developers. Since the majority trees are not tied to a mailing list,
many reports will become private emails if not CC kernel-janitors.
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
