Daniel P. Berrangé <berra...@redhat.com> writes: > 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.
Point.
