[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

Steven Rostedt rostedt at goodmis.org
Tue Jun 19 17:48:05 UTC 2012


On Tue, 2012-06-19 at 12:38 -0500, Jason Wessel wrote:

> Are you saying that patchcheck can check a single patch for the scope
> of what it changed and potentially output all the KCONFIG options that
> affect any macro definition changes or ifdefs in the code and generate
> a complete series of X number of kernels to compile to prove you
> didn't break anything?

Sorry, I didn't say that ;-)

>   If so, I want that tool, I didn't think such a
> thing existed.  Any randconfig takes you only so far, where as you
> could weight things against #ifdefs that are in the file, vs #ifdefs
> that are in the include files, vs the macros used in the file and
> their origin etc...  The patchcheck really only appears to compile
> a single case for bisection, but one never knows what ktest.pl will
> have it in by the end of the year. :-)

Hmm, we may not be able to get to the full #ifdefs, but perhaps a
subset. I think full #ifdef parsing is similar to the halting problem.

> 
> Bisection with one config is one thing, and yes, I too have
> "framework" for that.  Bisection with arbitrary configs and the
> dependent sets of variables that affect a subsystem is another.  I
> have a very, very minimal way that I test this with a list of specific
> options and any previous case where I have broken linux-next is in
> that list of course, and of course I wish it never happened in the
> first place.

ktest by default just does a bisect skip when it hits a build or boot
error if you are doing a test (or build if you are doing a boot test).

> 
> On a slightly different tangent, I would love to have a tool to help
> bisect .config runtime failures.  The ktest.pl is the closest thing I
> know of, it doesn't work for some cases.  Luckily I don't have to do
> this too often.  The last time I had to do it, I almost created a
> tool, because ktest will not handle the case of bad not being a subset
> of good config options as of yet.

I'm in the process of fixing that. It may or may not be ready by kernel
summit.

-- Steve




More information about the Ksummit-2012-discuss mailing list