Willy Tarreau <w@1wt.eu> writes:

quoted text
> Linux is the *only* product which requires
> the bug reporter to find the fault change (yes, I know, it's scalable).

It's a pretty common procedure for compilers (gcc, llvm) too, although
they have the advantage that given a test case usually someone else
can run the bisect procedure because they do not depend on the underlying
hardware 

That's unfortunately not the case for most kernel bugs, although
sometimes it is possible given a hardware independent test case. And
while most of the kernel code is drivers and arch, a lot of it is
still pretty hardware independent, so at least in some cases it is
possible to submit test cases and then let someone else (like a bug
master) do the bisect.

Of course it is unclear if producing a submittable test case will be
actually any faster than just running bisect for the user.

That said I agree it's a big burden to run bisect for everything
because it can take very long (especially if the problem
is not trivially reproducable) 

It would be fair at least if maintainers always gave some candidate
commit ids when asking for bisect for likely changes that could
have matched the bug.  Then those could be checked quickly first
before doing the full run.

While that will not always work it would be still a useful short cut
and save a lot of time for the reporter.

-Andi
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/