[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1411736128.7866.46.camel@x220>
Date: Fri, 26 Sep 2014 14:55:28 +0200
From: Paul Bolle <pebolle@...cali.nl>
To: Matt Fleming <matt@...sole-pimps.org>
Cc: Valentin Rothberg <valentinrothberg@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [GIT PULL] EFI urgent fixes
On Fri, 2014-09-26 at 13:34 +0100, Matt Fleming wrote:
> On Fri, 26 Sep, at 01:59:15PM, Paul Bolle wrote:
> >
> > I have a 800 line perl monster that checks for stuff like this. It's not
> > very sophisticated but smart enough to spot typos like this one. I try
> > to have it check each linux-next (and mainline) release.
>
> Very cool.
Thanks.
> > (I think Valentin Rothberg is trying to automate this properly. See
> > http://www.linuxplumbersconf.org/2014/ocw/sessions/1863 .)
>
> Have either of you guys thought about asking for this to be included
> with the 0-day kbuild bot or submitted under scripts/?
>
> It certainly seems like a useful bit of functionality.
I've been testing things locally for three months now. People must have
noticed an uptick in messages I send on this topic. (And, related, a
decrease in the numbers of cleanup patches I send myself.) I've not been
shouted at very often, so the signal to noise ratio is probably cool.
This is about the third time I've written a monster like that. (I first
started checking for Kconfig related defects in, I think, 2011.)
About the only thing I'm happy with in this attempt is that it parses
blobs separately. Ie, every release it checks for previously unseen
blobs, parses those, and saves each blob level parse as a git note to
that blob. Then it collects all relevant blob level notes, does the
aggregate analysis and reports the issues it identifies. That report is
saved away again as a note on the tag I'm checking. (I have not bothered
to automate that last step.) The neat thing is, I think, that each
release touches only a minority of files so parsing the tree is mostly a
one time cost (encountered on the very first run).
But, anyhow, I'm pretty sure Valentin is onto something much more
sophisticated.
> Fengguang, the interesting bits of this thread start here,
>
> https://lkml.kernel.org/r/1411730854.7866.10.camel@x220
Paul Bolle
--
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