Re: [Qemu-devel] [PATCH v3 02/11] iotests: Do not redirect qemu's stderr

[Max Reitz <mreitz@redhat.com>]

On 2015-02-25 at 21:29, Fam Zheng wrote:
> On Wed, 02/25 09:01, Max Reitz wrote:
>> On 2015-02-25 at 02:04, Fam Zheng wrote:
>>> On Tue, 02/24 10:35, Max Reitz wrote:
>>>> Redirecting qemu's stderr to stdout makes working with the stderr output
>>>> difficult due to the other file descriptor magic performed in
>>>> _launch_qemu ("ambiguous redirect").
>>>>
>>>> There is no harm in leaving stderr on stderr, so do it.
>>>>
>>>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>>>> ---
>>>> If someone has a better solution, especially regarding the redirection
>>>> to a subshell here (tests 091 and 109) and in the next patch, I'd be
>>>> very grateful. All of my efforts to pipe the output of the _launch_qemu
>>>> function resulted in said error ("ambiguous redirect"), so I had to keep
>>>> it on stderr and I did not find another way to pipe stderr to another
>>>> program.
>>> It will be much less hacky if we compare to a separate stderr reference
>>> (tests/qemu-iotests/109.err), similiar to QAPI tests, or just ignore stderr
>>> where we don't really care.
>> Hm, I'll take a shot at it. I hope it'll work; but even if it does, it
>> doesn't feel really right. I'd rather like having stdout and stderr mixed
>> because that gives us context for the stderr messages (without having to add
>> a ton of echo 1>&2 into the tests); also, doing so will probably result in a
>> lot of tests needing to be fixed (because then it won't only potentially
>> break tests using common.qemu, but every test which outputs something to
>> stderr). So in the end I'm not sure whether this is a better solution...
> It can be optional and only used where it makes our life easier.

Okay, if there is no .err file, we could just do as before.

> But in this
> case I don't mind simply dropping the friendly warning about implicit raw
> format probe - the test script does this intentionally.

Hm, okay, but that would still mean modifications to 109.

Talking about "optional", I could add a flag to _launch_qemu whether to 
redirect stderr to stdout or not. That way, at least existing tests can 
stay as they are.

> Are you sure the process substitution "2> >(grep ...)" in this patch produces
> deterministic output? Because two processes at both ends of the pipe write to
> stdout...

Apparently so. For me at least, the (filtered) stderr output appears 
always after all stdout output, so I'm guessing execution of the 
subshell is delayed until the process has exited.

Max