On Fri, Sep 06, 2024 at 10:52:53AM +0100, Peter Maydell wrote: > On Fri, 6 Sept 2024 at 09:14, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Fri, Sep 06, 2024 at 08:16:31AM +0200, Thomas Huth wrote: > > > On 05/09/2024 23.03, Fabiano Rosas wrote: > > > > Hi, > > > > > > > > This series silences QEMU stderr unless the QTEST_LOG variable is set > > > > and silences -qtest-log unless both QTEST_LOG and gtest's --verbose > > > > flag is passed. > > > > > > > > This was motivated by Peter Maydell's ask to suppress deprecation > > > > warn_report messages from the migration-tests and by my own > > > > frustration over noisy output from qtest. > > This isn't what I want, though -- what I want is that a > qtest run should not print "warning:" messages for things > that we expect to happen when we run that test. I *do* want > warnings for things that we do not expect to happen when > we run the test.
Currently we just allow the child QEMU process stdout/err to inherit to the qtest program's stdout/err. With that approach we have to do filtering at soruce (ie in QEMU itself). I feel that in general it is a bad idea for the program being tested to alter itself to suit the test suite, not least because two different parts of the test suite may have differing views about what messages they want to ignore vs display. We could address this be switching to the model used with IO tests. Always capture the child QEMU process stdout/err to a pipe. The test program can apply regex filters to cull output that is expected & irrelevant, and then print out whatever is left over on its own stderr. That way all the filtering of undesirable messages would be exclusively in the test suite, not QEMU itself. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
