linux-kernel - Re: Reporting bugs and bisection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3ve2ls26p.fsf@localhost.localdomain>
Date:	Sun, 13 Apr 2008 17:36:38 -0700 (PDT)
From:	Jakub Narebski <jnareb@...il.com>
To:	david@...g.hm
Cc:	Stephen Clark <sclark46@...thlink.net>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Willy Tarreau <w@....eu>, Tilman Schmidt <tilman@...p.cc>,
	Valdis.Kletnieks@...edu, Mark Lord <lkml@....ca>,
	David Miller <davem@...emloft.net>, jesper.juhl@...il.com,
	yoshfuji@...ux-ipv6.org, jeff@...zik.org,
	linux-kernel <linux-kernel@...r.kernel.org>, git@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Reporting bugs and bisection

david@...g.hm writes:

> cross-posted to git for the suggestion at the bottom

[...]

> Elsewhere in this thread someone said that the pre-git way was to do a
> manual bisect where the developer would send patches backing out
> specific changes to find the problem. one big difference between that
> and bisecting the problem is that the manual process was focused on
> the changes in the area that is suspected of causing the problem,
> while the git bisect process goes after all changes. this makes it
> much more likely that the tester will run into unrelated problems
> along the way.
> 
> I wonder if it would be possible to make a variation of git bisect
> that only looked at a subset of the tree when picking bisect points
> (if you are looking for a e1000 bug, testing bisect points that
> haven't changed that driver won't help you for example). If this can
> be done it would speed up the reporters efforts, but will require more
> assistance from the developers (who would need to tell the reporters
> what subtrees to test) so it's a tradeoff of efficiancy vs simplicity.

Errr... the synopisis of git-bisect contains the following:

 git bisect start [<bad> [<good>...]] [--] [<paths>...]

so you can limit bisection to commits affecting specified subsystem.

P.S. Unfortunately git currently doesn't deal with directory renames,
so if there was sime big code restructuring one has to provide all
historic pathspecs.

-- 
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/