qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 3/5] iotests: change qmp_log filters to expec


From: John Snow
Subject: Re: [Qemu-devel] [PATCH v4 3/5] iotests: change qmp_log filters to expect QMP objects only
Date: Wed, 19 Dec 2018 12:29:49 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1


On 12/19/18 6:27 AM, Vladimir Sementsov-Ogievskiy wrote:
> 19.12.2018 14:07, Vladimir Sementsov-Ogievskiy wrote:
>> 19.12.2018 4:52, John Snow wrote:
>>> log() treats filters as if they can always filter its primary argument.
>>> qmp_log treats filters as if they're always text.
>>>
>>> Change qmp_log to treat filters as if they're always qmp object filters,
>>> then change the logging call to rely on log()'s ability to serialize QMP
>>> objects, so we're not duplicating that effort.
>>
>> As I understand, there still no use for qmp-object based filters (even after 
>> the
>> series), do we really need them? I'm afraid it's premature complication.
> 
> aha, sorry, missed that you use it in 206.
> But still not sure that it worth it. Isn't it better to just remove fields 
> from dict,
> which are unpredictable, instead of substituting them..
> 

I'd like to keep the QMP output a prettified version of the plaintext
output, and not have it omit things. You can make the case for changing
that behavior in a separate patch.

> The other idea here: if we want
> automatically logged qmp commands (qmp_log(), actually), it should filter 
> unpredictable
> things from output automatically, just by command, which is the first 
> argument. Caller
> should not care about it, as it may be derived from command, how to filter 
> it's output.
> And then, we just need a kind of dict of functions, which do not do something 
> like generic
> recursion, but specifically prepares common-test-output for the concrete 
> command...
> 

Feel free to enhance the test suite later to understand all the types of
commands and replies and scrub them automatically. For now, specifying
the filters matches behavior in much of the rest of the test suite and I
am not motivated to fix it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]