[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
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
More information about the Ksummit-2012-discuss