qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump mo


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command
Date: Mon, 22 Apr 2013 15:00:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 22/04/2013 14:50, Luiz Capitulino ha scritto:
> On Mon, 22 Apr 2013 11:37:15 +0200
> Paolo Bonzini <address@hidden> 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).  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).

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]