Messages in this thread | | | Subject | Re: Reporting bugs and bisection | From | Andi Kleen <> | Date | Mon, 14 Apr 2008 11:58:08 +0200 |
| |
Willy Tarreau <w@1wt.eu> writes:
> 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
| |