Cc: Rafael J. Wysocki <rjw@...>, Tilman Schmidt <tilman@...>, <Valdis.Kletnieks@...>, Mark Lord <lkml@...>, David Miller <davem@...>, <jesper.juhl@...>, <yoshfuji@...>, <jeff@...>, <linux-kernel@...>, <netdev@...>, Andrew Morton <akpm@...>
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
--
