[Qemu-devel] Re: Should QMP be RPC to internal C interfaces?

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/30/2010 11:16 AM, Luiz Capitulino wrote:
> On Mon, 30 Aug 2010 10:38:45 -0500
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>    
>> On 08/30/2010 10:28 AM, Anthony Liguori wrote:
>>      
>>> Having two interfaces guarantees failure.  What's the separation
>>> between internal and external?  Is qdev internal or external?
>>>        
>> Let me put it another way, compatibility cannot be an after thought.
>>
>> We need to think deeply about compatibility when we design our
>> interfaces and we're going to have to redesign interfaces with
>> compatibility in mind.  It's a hard problem but it's solvable.  Just
>> defaulting arguments in QMP doesn't do anything to improve compatibility.
>>      
> The point is: C compat sucks, QMP's doesn't. QMP will suck too if we direct
> map the two.
>    

Prove it because I don't believe you :-)

Here's a counter example.  Let's say we have function do_something that 
takes three arguments.  We add a forth additional argument and default 
it.  And old client can call with three arguments and it just works 
because the default is "do what we used to do".

How do we discover if this new version of do_something supports four 
arguments instead of three?  Do we ignore unknown arguments?  We can't 
because that fourth argument may be important (but guess what, we do 
today and that's busted).  Because I might be passing "do something new" 
as the fourth argument because I expressly didn't want the old behavior.

Okay, so now we have to add a mechanism to enumerate function names and 
their arguments.  Now I can detect the fourth argument.  What if the 
argument is a structure and we want to add a new field to the structure?

How do I know, as a client, that I can add another field to the 
structure and that field will be respected?

You'd end up writing a full blown schema and then enforcing the schema.  
As a client, you'd have to download the schema and then try to detect 
the features a command supported.  That's an absolutely awful compat 
interface IMHO especially if you have different downstream schemas.

On the other hand, introducing a new function that takes a fourth 
argument, or a new type of structure with an added argument simplifies 
the problem tremendously.  It means we might have four versions of the 
same function but that's unavoidable.  Flattening this for the client 
makes their lives much simpler.

>> We cannot radically change our internal implementations and expect to
>> bridge it all in some special sauce code somewhere.
>>
>> This also suggests that we're going to have to practice deprecation to
>> evolve our APIs in a reasonable fashion.
>>      
> Deprecation should be mostly used for bad defined commands, not for simple
> extensions.
>    

It's better to talk about concrete things so please give an example of 
how you can provide compatibility in QMP that you can't do in C and we 
can discuss it.

My position is that we aren't any closer to having compatible APIs then 
we were with the human monitor.  I think we need to focus on 
compatibility and that that has to be solved as the QEMU interface 
level.  I contend that it's not solvable at the QMP level.

Regards,

Anthony Liguori

Regards,

Anthony Liguori