From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OBT00-0004uc-0y for qemu-devel@nongnu.org; Mon, 10 May 2010 09:26:20 -0400 Received: from [140.186.70.92] (port=53121 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBSzt-0004t0-Pr for qemu-devel@nongnu.org; Mon, 10 May 2010 09:26:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBSzo-0003D0-3P for qemu-devel@nongnu.org; Mon, 10 May 2010 09:26:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14457) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBSzn-0003Co-SM for qemu-devel@nongnu.org; Mon, 10 May 2010 09:26:08 -0400 Date: Mon, 10 May 2010 10:26:01 -0300 From: Luiz Capitulino Message-ID: <20100510102601.3898a601@redhat.com> In-Reply-To: <4BE7E723.3000002@siemens.com> References: <4BE3FD3F.4070606@siemens.com> <20100507100758.1050a374@redhat.com> <4BE421D9.30502@siemens.com> <20100507135902.2753bb4a@redhat.com> <4BE7E723.3000002@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Registering buffers with a qdict List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On Mon, 10 May 2010 12:59:47 +0200 Jan Kiszka wrote: > Luiz Capitulino wrote: > > On Fri, 07 May 2010 16:21:13 +0200 > > Jan Kiszka wrote: > > > >> Luiz Capitulino wrote: > >>> On Fri, 07 May 2010 13:45:03 +0200 > >>> Jan Kiszka wrote: > >>> > >>>> Hi Luiz, > >>>> > >>>> what is the recommended way of pushing larger buffers (up to 64K so far) > >>>> into a qdict? QLIST of QINT (one per byte) looks a bit heavy. I thought > >>>> about hex-encoding the content first (series of "%02X"), then > >>>> registering it as QSTRING. Or should we introduce a new type, QBUFFER? > >>> I don't think that hex-encoding the contents is so bad if your use case is > >>> very specific and isolated. > >> The focus will be first on visualizing the buffer (user_print), but who > >> knows what happens once the services is also exposed via QMP. > >> > >>> On the other hand, I do prefer a QBuffer type, specially because we can > >>> have buffer operations. > >> The q.c files look sufficiently simply, guess I will add a buffer > >> type. Still, hex-encoding is probably the best representation for QMP. > > > > Yes, either as a string or (as suggested by Markus) an array of numbers, > > if you wish to expose this via QMP you (or any of us) will have to update > > the parser to support it. > > From a quick glance at the JSON spec, there is no room for a new type. I > think we have to overload an existing one and convert that into a > QBuffer (typically, we know the actual semantic). Hex string encoding is > most compact, so I went this road. But I'm open to change it into a true > type if JSON actually allows it (or we are fine with breaking it). We have capabilities support but I don't think we should use it for this case. We can have QBuffer internally and the parser can convert it to a valid json type.