From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUK9k-0002Bg-SH for qemu-devel@nongnu.org; Mon, 22 Apr 2013 13:03:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUK9g-0006qB-8v for qemu-devel@nongnu.org; Mon, 22 Apr 2013 13:03:56 -0400 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]:55602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUK9g-0006q4-5s for qemu-devel@nongnu.org; Mon, 22 Apr 2013 13:03:52 -0400 Received: by mail-qc0-f169.google.com with SMTP id t2so2285443qcq.14 for ; Mon, 22 Apr 2013 10:03:51 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51756D68.1050705@redhat.com> Date: Mon, 22 Apr 2013 19:03:36 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1366275680-15416-1-git-send-email-kraxel@redhat.com> <87ppxq6hmn.fsf@blackfin.pond.sub.org> <5174DEE5.20406@redhat.com> <517504CB.6040303@redhat.com> <20130422085043.4a3e891c@redhat.com> <51753471.5080803@redhat.com> <8738uiqzm1.fsf@codemonkey.ws> In-Reply-To: <8738uiqzm1.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Markus Armbruster , Gerd Hoffmann , qemu-devel@nongnu.org, Luiz Capitulino Il 22/04/2013 18:49, Anthony Liguori ha scritto: >> We've been adding fields to types since 0.15, sometimes in the middle of >> a struct (since 1.2). > > You can safely add fields to the end of a struct. For QEMU->user structs it is. For user->QEMU structs you need to add a sizeof() at the beginning, or ensure that everything is heap-allocated (and zero-initialized). At that point you could also use structs to pass arguments to the functions (in the C client API) that execute a QMP command. That's similar to having keyword arguments in C. > Well this is all well and good in abstract, in practice, we want a new > screendump command anyway. > > It'd be *much* nicer to return the screenshot data via the QMP session > instead of writing it to a file. So let's take the opportunity to fix > the command. That's debatable... the "nicest" way could also be to pass a pipe fd and retrieve the dump from that fd. That's quite easy to do with fdsets. The choice is between implementing SCM_RIGHTS sendfd and a base64 decoder. > We can also introduce a "format" parameter to allow specifying formats > othe than PPM. True, but I'm not sure we want to go there. We'd need to add support for options like JPG quality factor etc. Paolo