From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoDij-0004Jk-3L for qemu-devel@nongnu.org; Fri, 01 May 2015 12:23:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoDie-0006vd-Ng for qemu-devel@nongnu.org; Fri, 01 May 2015 12:23:21 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:35044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoDie-0006vX-Gy for qemu-devel@nongnu.org; Fri, 01 May 2015 12:23:16 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 May 2015 10:23:15 -0600 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id AE88D1FF0045 for ; Fri, 1 May 2015 10:14:23 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t41GND0p48627764 for ; Fri, 1 May 2015 09:23:13 -0700 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t41GNDcT019196 for ; Fri, 1 May 2015 10:23:13 -0600 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Michael Roth In-Reply-To: <20150501161905.11253.15908@loki> References: <1429975686-19494-1-git-send-email-ehabkost@redhat.com> <553BC973.2030506@suse.de> <20150427172320.GC25766@thinpad.lan.raisama.net> <20150429083802.06f102ea@redhat.com> <20150429125548.GF25766@thinpad.lan.raisama.net> <20150501161905.11253.15908@loki> Message-ID: <20150501162309.11253.4357@loki> Date: Fri, 01 May 2015 11:23:09 -0500 Subject: Re: [Qemu-devel] [PATCH] QJSON: Use OBJECT_CHECK List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Luiz Capitulino Cc: agraf@suse.de, qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= , Juan Quintela 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 wrote: > > > = > > > > On Sat, Apr 25, 2015 at 07:05:55PM +0200, Andreas F=C3=A4rber wrote: > > > > > Am 25.04.2015 um 17:28 schrieb Eduardo Habkost: > > > > > > The QJSON code used casts to (QJSON*) directly, instead of OBJE= CT_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 > > > > > > --- > > > > > > qjson.c | 10 +++++----- > > > > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > > = > > > > > Reviewed-by: Andreas F=C3=A4rber > > > > > = > > > > > Wasn't aware QJSON is using QOM - assuming this will go through s= ome > > > > > 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. > = > > = > > -- = > > Eduardo > >=20