Re: [Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1

[Even Rouault]

Thanks for the tutorial on how to use git bisection ;-)
In fact, whatever version control system you use, I think you spend most of 
time recompiling and testing stuff...

Anyway, on the core problem I'm pointing out, does someone have any clue on 
what should be done ? Should the revision 1.24 of 
hw/pckbd.c ("QEMU keyboard issue with Gujin-2.2") be reverted ? Is there a way 
to get FC4 to work again, and "Gujin" at the same time ? Is the patch of 
revision 1.24 the right fix for Gujin and another additionnal fix is required 
for the FC4 issue (presumably related to Linux kernel version 2.6.11) or 
should it be reverted and a better fix found for Gujin ?

I tried to follow the discussion about that topic 
(http://www.mail-archive.com/qemu-devel%40nongnu.org/msg12455.html) but I'm 
afraid I'm lost in the details.

Best regards

Le Monday 21 January 2008 00:54:27, vous avez écrit :
> Hi,
>
> On Sun, 20 Jan 2008, Even Rouault wrote:
> > After quite a lot of CVS bisection, [...]
>
> Not wanting to advertise git, but to help other people needing to bisect
> efficiently: here is a recipe how to do this with git.
>
> 1. get git (obviously)
>
> 2. $ git clone git://repo.or.cz/qemu.git/
>    (it is a git mirror of git://git.kernel.dk/data/git/qemu.git, so if you
>     do not want to be nice to Jens' server, you can go there directly)
>
> 3. Find out what was the last good revision.  If you have an approximate
>    date take the first "commit" of the output of
>
>       $ cd qemu/
>       $ git log --until="2007/09/07"
>
>    (It would show a line beginning with "commit " and followed by a
>     40-character hex sequence; copy that sequence)
>
> 4. Start the bisection
>
>       $ git bisect start
>       $ git bisect bad HEAD
>       $ git bisect good 85f8a4e8bae4df3983a5f1efd62b7942417bb89b
>
>    Obviously, you have to use the sequence you copied in 3.
>
> 5. Compile, test, and call
>
>       $ git bisect good
>
>    or
>
>       $ git bisect bad
>
>    after the test, depending if the tested revision is good or -- you
>    guessed it -- bad.
>
> 6. Repeat 5. until git tells you which is probably the bad commit.  Then
>    scrap this clone, or go back to the CVS HEAD with
>
>       $ git bisect reset
>
> You are literally guaranteed to test the minimal amount of revisions with
> this procedure.
>
> Hth,
> Dscho