Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/12/2011 02:42 PM, Avi Kivity wrote:
> On 03/10/2011 06:04 PM, Anthony Liguori wrote:
>> On 03/10/2011 09:45 AM, Avi Kivity wrote:
>>>>
>>>>> btw2, I now nominate subscribe and unsubscribe as replacements for 
>>>>> get and put.
>>>>
>>>> Subscribe implies sub/pub in my mind and we're not publishing 
>>>> events so I don't think it fits the model.
>>>>
>>>> A pub/sub event model would be interesting to think through but 
>>>> without a global namespace and object model, I don't think we can 
>>>> make it fit well.
>>>
>>> I feel we're still not communicating.  What does 'get-*-event' mean?
>>>
>>> I think you're using some nomenclature that is unfamiliar to me.
>>
>> No, I'm just defending something that I think fundamentally sucks.
>>
>> I very purposefully am trying to avoid heavy protocol visible changes 
>> at this stage.  The only reason I added signal accessors is that the 
>> current event model is unusable from a C API.
>>
>> I am in full agreement that the current signal model needs to be 
>> rethought and should be changed at the protocol level.  I just don't 
>> want to do that right now because there are a ton of internal 
>> improvements that can be made by without doing that.
>>
>> The signal accessors are ugly but they're just a handful of commands 
>> that can be deprecated over time.  We should revisit events but we 
>> should take the time to design it and plan for a protocol addition 
>> for 0.16.
>
> It would be much better to avoid introducing deprecated commands.  
> They're a maintenance burden for both server and client, and a testing 
> burden as well.  I feel it's better to spend more time to get 
> something we truly like.

I'm really not interested in getting something I like.  We're at a 
deadlock right now with QMP.  It's essentially not usable on its own 
because there are so few commands implemented.  As we speak, the libvirt 
guys are adding new features based on monitor commands because they've 
waited too long for the QMP versions to show up.

And more monitor commands keep getting added often without a QMP 
version.  There's almost no incentive to care about QMP because it's not 
that useful.  We need to break the deadlock and make QMP useful.  That's 
the goal of this effort.

The only reason I even touched events is because the current event 
infrastructure is so broken.  They cannot be consumed internally in any 
meaningful way which means they fall into the not useful bucket.

If there was an obvious alternative, I'd switch to it.  But it's not as 
easy as it sounds.  If you have a protocol level connect, then you need 
a way to expose events at the protocol level to a client.  You could use 
an accessor and return a signal object but then you have a complicated 
life cycle.

When you return a signal object to a QMP client, the object needs to 
persist until 1) the session goes away 2) the object is explicitly 
released by the client.  On top of this, you also have connections which 
introduce a second life cycle.

In reality, do you ever want to get a handle to a signal without 
connecting to it?  I doubt it.  So if you make connecting to an signal 
implicit in accessing it, then you only have to deal with one life 
cycle, the signal connection.  This is the current implementation.

There are nicer models but they really require having an object model 
whereas the signals are properties of the objects.  That means you don't 
have to deal with an extra life cycle (because there is no explicit 
signal object).

But really, this is one of the least important things we need to worry 
about.  The number of commands we have with extremely hard to use 
semantics are alarming.  The change command caused us a CVE because it's 
semantics are so subtle.  device_del has caused device detach to be 
fundamentally broken in libvirt because it's semantics are subtle and 
undocumented.   These are the important problems to solve.  It's not as 
sexy as a JSON RPC signalling model, but it's far more important.

Regards,

Anthony Liguori