From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44299)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1a1Cyt-0007cw-PF
	for qemu-devel@nongnu.org; Tue, 24 Nov 2015 07:46:03 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1a1Cys-0000Ws-TX
	for qemu-devel@nongnu.org; Tue, 24 Nov 2015 07:45:59 -0500
From: Markus Armbruster <armbru@redhat.com>
References: <1448342531-16407-1-git-send-email-famz@redhat.com>
	<1448342531-16407-13-git-send-email-famz@redhat.com>
	<56544F43.3090603@redhat.com>
Date: Tue, 24 Nov 2015 13:45:49 +0100
In-Reply-To: <56544F43.3090603@redhat.com> (Paolo Bonzini's message of "Tue,
	24 Nov 2015 12:51:31 +0100")
Message-ID: <87y4dn36rm.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH for-2.6 12/14] qemu-img: In 'map',
	use QDict to generate JSON output
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, qemu-block@nongnu.org, Jeff Cody <jcody@redhat.com>, Peter Lieven <pl@kamp.de>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 24/11/2015 06:22, Fam Zheng wrote:
>>      case OFORMAT_JSON:
>> -        printf("%s{ \"start\": %"PRId64", \"length\": %"PRId64", \"depth\": %d,"
>> -               " \"zero\": %s, \"data\": %s",
>> -               (e->start == 0 ? "[" : ",\n"),
>> -               e->start, e->length, e->depth,
>> -               (e->flags & BDRV_BLOCK_ZERO) ? "true" : "false",
>> -               (e->flags & BDRV_BLOCK_DATA) ? "true" : "false");
>> +        if (e->start == 0) {
>> +            printf("[");
>> +        } else {
>> +            printf(",");
>> +        }
>> +
>> +        dict = qdict_new();
>> +        qdict_put(dict, "start", qint_from_int(e->start));
>> +        qdict_put(dict, "length", qint_from_int(e->length));
>> +        qdict_put(dict, "depth", qint_from_int(e->depth));
>> +        qdict_put(dict, "zero", qbool_from_bool(e->flags & BDRV_BLOCK_ZERO));
>> +        qdict_put(dict, "data", qbool_from_bool(e->flags & BDRV_BLOCK_DATA));
>>          if (e->flags & BDRV_BLOCK_OFFSET_VALID) {
>> -            printf(", \"offset\": %"PRId64"", e->offset);
>> +            qdict_put(dict, "offset", qint_from_int(e->offset));
>>          }
>> -        putchar('}');
>> +        str = qobject_to_json(QOBJECT(dict));
>> +        printf("%s\n", qstring_get_str(str));
>
> I think it's better if you use QAPI for this.  You can make MapEntry a
> QAPI struct and generate the QObject through a QMP visitor.
>
> The reason is that we could add JSON visitors that let us parse or
> produce JSON without going through the expensive QObject creation.  Even
> though that is far away, the least explicit QObject manipulation we
> have, the better.

I concur.

Manual messing with QDict is of course fine when a higher-level
interface doesn't fit.  But here, we serialize a struct to JSON, and
that's something QAPI is meant to do.  Having to define a QAPI type may
be a bit of a bother, but once that's done, the "serialize this struct
to JSON" code becomes less tedious.  qemu-img.c already has a few
examples; search for qmp_output_visitor_new().