[vfio-users] Interrupt Handling: Regression or config change?

[Manuel Ullmann]

Torbjorn Jansson <torbjorn.jansson at mbox200.swipnet.se> writes:

> On 2017-01-12 19:49, Laszlo Ersek wrote:
>> On 01/12/17 19:21, Ede Wolf wrote:
>>> Besides my fighting with git, is it correct, that the working kernel is
>>> labeld "bad", while the non working one "good"? May very well possible
>>> for the workflow of dissect, just want to confirm, please
>>>
>>>> git bisect start
>>>> git bisect bad v4.5.4
>>>> git bisect good v4.6.1
>>
>> No. git-bisect always locates a regression, that is, the first commit
>> that introduces a bug. Where things go from right to wrong. If this
>> matches your situation (old version works, new version breaks), simply
>> use the "good" and "bad" command line arguments verbatim.
>>
>> Now, if you are looking for a commit that fixes a known bug, i.e., old
>> version is broken, new version works, but you don't exactly know what
>> fixed it, then you have to invert the meanings. Whenever the commit
>> under testing works, you have to say "bad", and whenever it breaks, you
>> have to say "good". More modern git versions help automate this (for
>> less boggling of the mind) with "git bisect terms". (See the manual.)
>> With older git versions, git command aliases, shell aliases, or small
>> wrapper scripts can hide the confusion.
>>
>> Given that you are facing a real regression, you should use the good/bad
>> terms verbatim. From your earlier email, "4.5.7" works, "4.6" breaks,
>> hence you should qualify the former with "good", and the latter with "bad".
>>
>> Also, the word is "bisect", not "dissect".
>>
>> https://en.wiktionary.org/wiki/bisect
>> https://en.wiktionary.org/wiki/dissect
>>
>> git-bisect performs a binary search, halving commit ranges. Hence the
>> "bi" in "bisect".
>>
>> Laszlo
>
> it is also important when bisecting to make 100% sure you tell git the
> right thing after testing each build.
> this can be complicated if some builds don't compile properly and
> prevents you from building and testing that specific version.
>
> also binary search means you cut the problem into two halves each time
> and when you tell git if it is bad or good, this means you throw away
> that half of the problem and then repeat the process to further
> isolate the issue.
>
> all of this is automated by git bisect, but it all depends on picking
> a good and bad commit to start with and then making sure you tell git
> if the current version you are testing is really good or bad.
>
>
> when i tried git bisect the first time i screwed up because of this.
> then i did it right and also kept track of what commits i was testing
> (the output of each git bisect) since some of the versions did not
> build so i had to restart the bisect at a different point.
>
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
Hi,

yes, all of this should be considered. But let’s cut it down to the use
case again:

In the unlikely case, that a kernel does not compile, you would let git
choose a nearby commit, that hopefully works, with:
git bisect skip

If you marked a commit with the wrong term e.g. good instead of
bad, you can revert it by doing the following in linux source root:
git bisect log > ../mistake.log
git bisect reset
## Assuming EDITOR is set to your favorite text editor, see
## https://wiki.archlinux.org/index.php/Environment_variables
## for further info. Note, it should at least have a non-graphical mode.
$EDITOR ../mistake.log # remove the line with the wrong marking
git bisect replay ../mistake.log

Obviously you can use bisect log also, when you are not sure, that you
marked a commit correctly.

Also the terms syntax is available with git-2.11.0 being in Arch
stable, but in this case the good and old keywords already make sense,
because 4.5.x releases are good and 4.6.x releases are bad. So renaming
those is not required.

Anyway, just have a look at the git-bisect manpage. It is actually quite
good, but I got confused by some particular syntax, that has been
clarified with a committed patch:

The description section regarding terms can be confusing. It
states:

           git bisect (bad|new) [<rev>]
           git bisect (good|old) [<rev>...]

Now you could wonder (I did), that bad is not the opposite of new, but
actually it is ordered according to the dots syntax. Both good and old
do allow multiple revisions as arguments, while bad/new do not. When I
asked at the mailing list about that, my thinking also confused a
developer at first until he recalled the intention again. So there is a
patch released changing this into

           git bisect (bad|new|<term-new>) [<rev>]
           git bisect (good|old|<term-old>) [<rev>...]

Best regards,
Manuel

PS: In the unlikely case, that you have any trouble translating English,
you could exchange understanding issues with me off the list in German.