From: Anthony Liguori <aliguori@us.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command
Date: Mon, 22 Apr 2013 11:49:58 -0500 [thread overview]
Message-ID: <8738uiqzm1.fsf@codemonkey.ws> (raw)
In-Reply-To: <51753471.5080803@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 22/04/2013 14:50, Luiz Capitulino ha scritto:
>> On Mon, 22 Apr 2013 11:37:15 +0200
>> Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>> Il 22/04/2013 08:55, Gerd Hoffmann ha scritto:
>>>>>>>> Question for the libvirt guys: Is it ok for libvirt to just extend the
>>>>>>>> existing screendump command? Can libvirt figure there is a new
>>>>>>>> (optional) parameter? See patch #5.
>>>>>>
>>>>>> Nope, QMP can't do that. I argued for such capabilities, but the
>>>>>> "create a new command" philosophy prevailed.
>>>>>>
>>>>>> Go forth and multiply commands! And have fun picking command names that
>>>>>> aren't fugly.
>>>> Oh joy. Lets just enumerate things & use "screendump2" ...
>>>
>>> QMP can't do that _yet_.
>>>
>>> Let's fix it instead...
>>
>> The point is that we have chosen not to do so a while ago. In a nutshell,
>> Anthony thinks that we should have the same compatibility contract of
>> a C API.
>
> 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. If you think about it
in terms of a shipped qmp.h file, it would be:
struct CharInfo
{
};
CharInfo *qmp_query_char(QMPSession *session, Error **errp);
But adding parameters to functions breaks the ABI and there's no way
around unless you make all parameters passed as a single structure.
> If the C API is a requirement, it should also be
> a requirement for structs. But there are plenty of ways (some nicer,
> some uglier) to have different API versions in C.
>
> For example, I think the QIDL patch had ways to annotate each parameter
> independently. You can annotate each argument with the "first version
> this appeared in" and complicate the C API generator to generate
> multiple C functions for the same command.
>
> It is then the downstream's responsibility not to backport extra
> arguments without a full-blown rebase to a newer version (the same as
> for C libraries).
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.
We can also introduce a "format" parameter to allow specifying formats
othe than PPM.
Regards,
Anthony Liguori
>
> Paolo
next prev parent reply other threads:[~2013-04-22 16:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 9:01 [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command Gerd Hoffmann
2013-04-18 9:01 ` [Qemu-devel] [PATCH 1/5] console: qom-ify QemuConsole Gerd Hoffmann
2013-04-18 9:01 ` [Qemu-devel] [PATCH 2/5] console: Hook QemuConsoles into qom tree Gerd Hoffmann
2013-04-18 9:01 ` [Qemu-devel] [PATCH 3/5] console: add device link to QemuConsoles Gerd Hoffmann
2013-04-18 9:01 ` [Qemu-devel] [PATCH 4/5] console: add qemu_console_lookup_by_device Gerd Hoffmann
2013-04-18 9:01 ` [Qemu-devel] [PATCH 5/5] console: extend screendump monitor cmd Gerd Hoffmann
2013-04-18 12:10 ` [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command Eric Blake
2013-04-18 15:21 ` Luiz Capitulino
2013-04-18 15:34 ` Eric Blake
2013-04-22 7:19 ` Gerd Hoffmann
2013-04-19 8:37 ` Markus Armbruster
2013-04-19 13:03 ` Eric Blake
2013-04-22 6:55 ` Gerd Hoffmann
2013-04-22 9:37 ` Paolo Bonzini
2013-04-22 12:50 ` Luiz Capitulino
2013-04-22 13:00 ` Paolo Bonzini
2013-04-22 16:49 ` Anthony Liguori [this message]
2013-04-22 17:03 ` Paolo Bonzini
2013-04-22 17:23 ` Eric Blake
2013-04-23 5:15 ` Gerd Hoffmann
2013-04-22 17:56 ` Anthony Liguori
2013-04-23 11:57 ` Gerd Hoffmann
2013-04-25 20:55 ` Anthony Liguori
2013-04-25 21:17 ` Luiz Capitulino
2013-04-25 21:55 ` Eric Blake
2013-04-25 22:19 ` Anthony Liguori
2013-04-25 22:19 ` Anthony Liguori
2013-04-26 0:41 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738uiqzm1.fsf@codemonkey.ws \
--to=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.