Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message

[Anthony Liguori]

On 08/27/2010 02:24 PM, Luiz Capitulino wrote:
> > I don't see how 0.13.0 is going to get releases with anything but the
> > current behavior.  It's unfortunate but we're too delayed and can't
> > afford a change like this this late in the game.
> >
> > In terms of the stable branch, the least disruptive thing would be a
> > timeout.
> >      
> Okay.
>
>    
> > > I think we have agreed on the internal interfaces approach. My only
> > > concern is whether this will conflict when extending the wire protocol
> > > (eg. adding new arguments to existing commands). Not a problem if the
> > > C API is not stable, of course.
> > >
> > >        
> > We don't do that.  It's a recipe for disaster.  QEMU isn't written in
> > Python and if we try to module our interfaces are if we were a Python
> > library, we're destined to fail.
> >      
> You mean we don't do simple protocol extensions?
>
> So, if we need an new argument to an existing command, we add a new
> command instead? Just because QEMU is not written in Python?
>    

Because it's too easy to get it wrong in QEMU.  Here's the rationale.

If I can't trivially call a QMP function in C, then I'm not going to use 
QMP functions within QEMU.  I'm not going to create an embedded JSON 
string just to call a function with three integer arguments.

Yes, if we need to do that, we can create a C API that both the QMP 
interface uses and we also use internally but why?  All that does is 
introduce the chance that the C API will have more features than the QMP 
interface.

If we don't use these functions in QEMU, then how do we know that these 
functions have reasonable semantics?  This is exactly the problem we 
suffer today.  We have internal APIs that do reasonable things but 
everything that deals with QMP is a special case.  That creates too many 
opportunities to get things wrong.

I think it's a vitally important requirement that all future QMP 
functions have direct mappings to a C interface.  The long term goal 
should be for that interface to be used by all of the command line 
arguments, SDL, and the human monitor.  If those things only relied on a 
single API and we exposed that API via QMP, than we would have an 
extremely useful interface.

Regards,

Anthony Liguori