From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKyD1-0000xT-Gw for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:30:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKyCw-0000w5-QF for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:30:30 -0400 Received: from [199.232.76.173] (port=40063 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKyCw-0000w2-JO for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:30:26 -0400 Received: from mail-gx0-f227.google.com ([209.85.217.227]:44240) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKyCw-0007NR-5M for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:30:26 -0400 Received: by gxk27 with SMTP id 27so12739590gxk.10 for ; Sun, 28 Jun 2009 10:30:25 -0700 (PDT) Message-ID: <4A47A8AF.3030905@codemonkey.ws> Date: Sun, 28 Jun 2009 12:30:23 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> <4A43C264.6060803@redhat.com> <4A43D600.8060605@codemonkey.ws> <4A449113.8070907@redhat.com> <4A44CB74.1070808@codemonkey.ws> <4A44E2F3.8050804@codemonkey.ws> <5b31733c0906261036o272bcd8xffc0f2e209b778a5@mail.gmail.com> <4A45232F.50306@codemonkey.ws> <5b31733c0906261325ye5fe937wea277c2d87ccd1e1@mail.gmail.com> <4A476D46.2000909@redhat.com> In-Reply-To: <4A476D46.2000909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez Avi Kivity wrote: > On 06/26/2009 11:25 PM, Filip Navara wrote: >>> I don't think binary data is a requirement. An FDT should be >>> transmitted as >>> a tree, not as a binary blob. You could also transmit binary as a >>> list of >>> bytes though. >>> >> >> You can transmit it as list of bytes and it's woefully inefficient. I >> gave the FDT as an example, but I believe that binary data may be >> needed in future for one purpose or another. The monitor already >> provides a way to dump guest memory and I see no reason to not >> transfer it using some "binary" encoding. >> > > Another candidate is screendump. There's no reason to go through a > file. We could pass a pipe as an fd and request a screendump to that > fd, but that's rather roundabout. Instead of inventing binary syntaxes, maybe we could use dictionary syntax to denote a mime encoded value? So something like: {"Content-Type": "image/ppm", "Content-Transfer-Encoding": "base64", "Content": "AB234SDFSDf=="} A special brace format could be used if we wanted to make sure it was independently parsable: <"Content-Type": "image/ppm", "Content-Transfer-Encoding": "base64", "Content": "AB234SDFSDf=="> But I suspect dicts are good enough. Regards, Anthony Liguori