Re: [qemu-mainline test] 80469: regressions - FAIL

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
[snip]
> > ./configure of QEMU fail with:
> > "ERROR: invalid trace backends
> >         Please choose supported trace backends."
> >
> > They have remove the "stderr" tracebackend, and replaced it by "log".
> Which
> > also became the default. I have not look at what to do yet, but the
> configure
> > option "--enable-trace-backend=stderr" as became invalid.
> 
> Paul added this IIRC.
> 
> If it isn't immediately obvious what an appropriate replacement is (which
> remember needs to work with at least qemu-xen-unstable as well as qemu-
> upstream) then I think we should just remove this option from
> xen.git/tools/Makefile for the time being.
> 
> FWIW the bisector has fingered:
> 
>   commit ed7f5f1d8db06fc31352a5ef4f54985e630c575a
>   Author: Paolo Bonzini <pbonzini@redhat.com>
>   Date:   Thu Jan 7 16:55:30 2016 +0300
> 
>       trace: convert stderr backend to log
> 
>       [Also update .travis.yml --enable-trace-backends=stderr
>       --Stefan]
> 
>       Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>       Signed-off-by: Denis V. Lunev <den@openvz.org>
>       Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
>       Message-id: 1452174932-28657-10-git-send-email-den@openvz.org
>       Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> It looks like s/stderr/log/g would work with qemu-mainline, but we'd need
> that backported to qemu-xen-unstable too.
> 
> Or given:
>     git show --stat -M ed7f5f1d8db06fc31352a5ef4f54985e630c575a
>     [...]
>      scripts/tracetool/backend/{stderr.py => log.py} |  9 +++++----
> 
> Maybe xen.git/tools/Makefile could probe for the presence of these files?
> 

I don't think we should pull logging out... IMO it's too useful. (In fact I would prefer if libxl also kicked off qemu with a default events file that enabled logging from the platform device). If we can probe for the right thing to pass to configure then that seems like the best way to handle this (unless we want to keep different configuration recipes for different qemu tags/branches).

  Paul

> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel