[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] QJSON: Use OBJECT_CHECK

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] QJSON: Use OBJECT_CHECK
Date: Sat, 02 May 2015 16:44:25 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 01.05.15 18:23, Michael Roth wrote:
> Quoting Michael Roth (2015-05-01 11:19:05)
>> Quoting Eduardo Habkost (2015-04-29 07:55:48)
>>> On Wed, Apr 29, 2015 at 08:38:02AM -0400, Luiz Capitulino wrote:
>>>> On Mon, 27 Apr 2015 14:23:20 -0300
>>>> Eduardo Habkost <address@hidden> wrote:
>>>>> On Sat, Apr 25, 2015 at 07:05:55PM +0200, Andreas Färber wrote:
>>>>>> Am 25.04.2015 um 17:28 schrieb Eduardo Habkost:
>>>>>>> The QJSON code used casts to (QJSON*) directly, instead of OBJECT_CHECK.
>>>>>>> There were even some functions using object_dynamic_cast() calls
>>>>>>> followed by assert(), which is exactly what OBJECT_CHECK does (by
>>>>>>> calling object_dynamic_cast_assert()).
>>>>>> Suggest s/OBJECT_CHECK/OBJECT_CHECK()/g everywhere for clarity.
>>>> Everywhere? You mean, in other places? In this case someone has to
>>>> post a different patch.
>>> Just in the commit message.
>>>>> I assume it can be fixed during commit by whoever is going to queue it.
>>>>>>> Signed-off-by: Eduardo Habkost <address@hidden>
>>>>>>> ---
>>>>>>>  qjson.c | 10 +++++-----
>>>>>>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>>>>> Reviewed-by: Andreas Färber <address@hidden>
>>>>>> Wasn't aware QJSON is using QOM - assuming this will go through some
>>>>>> QAPI/QMP tree.
>>>>> The only user of qjson.c right now is migration code. Should it go through
>>>>> the migration tree?
>>>> It could be, but I can take it if nobody does.
>>> Thanks!
>>>>> Also, why do we have two JSON writers in QEMU? And why do they have
>>>>> exactly the same name?
>>>> Not sure I got it, which writers?
>>> qjson.c and qobject/qjson.c:to_json().
>> I'm guessing it's to avoid the need to build up a QObject throughout
>> the migration code, as opposed to just serializing metadata/vmstate
>> fields directly to string.
>> Does make me wonder though why we don't just use visit_type_{int,etc}()
>> interfaces to build up the QObject through a QMPOutputVisitor, then feed
>> the resulting QObject through the existing qobject/qjson.c code.
> I guess that would affect downtime. Don't imagine it would by much
> though. A JSONOutputVisitor that simply wraps JSONMessageParser
> and avoids the QObject intermediate might be another option.

Well, there were a number of reasons why I didn't want to use the
QObject json writer. The biggest one is complexity. We're really trying
to do something incredibly trivial, namely writing json string data
continuously. Allocating all that memory (potentially running oom)
didn't seem incredibly appealing to me.


reply via email to

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