Messages in this thread | | | Date | Mon, 14 Apr 2008 12:00:18 +0200 | From | Willy Tarreau <> | Subject | Re: Reporting bugs and bisection |
| |
On Mon, Apr 14, 2008 at 11:58:08AM +0200, Andi Kleen wrote: > 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.
And most of all, the reporter would not feel like the bisection is the default response !
> -Andi
Willy
| |