[Qemu-devel] Re: [RFC] qapi: events in QMP

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/14/2011 07:33 AM, Daniel P. Berrange wrote:
> On Mon, Feb 14, 2011 at 11:28:52AM -0200, Luiz Capitulino wrote:
>    
>> On Sun, 13 Feb 2011 12:08:04 -0600
>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>
>>      
>>> Hi,
>>>
>>> In my QAPI branch[1], I've now got almost every existing QMP command
>>> converted with (hopefully) all of the hard problems solved.  There is
>>> only one remaining thing to attack before posting for inclusion and
>>> that's events.  Here's my current thinking about what to do.
>>>
>>> Events in QMP Today
>>>
>>> QMP events are asynchronous messages.  They are not tied explicitly to
>>> any type of context, do not have a well defined format, and are have no
>>> mechanism to mask or filter events.  As of right now, we have somewhere
>>> around a dozen events.
>>>
>>> Goals of QAPI
>>>
>>> 1) Make all interfaces consumable in C such that we can use the
>>> interfaces in QEMU
>>>
>>> 2) Make all interfaces exposed through a library using code generation
>>> from static introspection
>>>
>>> 3) Make all interfaces well specified in a formal schema
>>>
>>> Proposal for events in QAPI
>>>
>>> For QAPI, I'd like to model events on the notion of signals and
>>> slots[2].  A client would explicitly connect to a signal through a QMP
>>> interface which would result in a slot being added that then generates
>>> an event.  Internally in QEMU, we could also connect slots to the same
>>> signals.  Since we don't have an object API in QMP, we'd use a pair of
>>> connect/disconnect functions that had enough information to identify the
>>> signal.
>>>        
>> This seems to be the right way to do this in C, but I wonder if it will
>> get complex/bloated to require this on the wire protocol.
>>
>> In the initial discussions on QMP events, we decided that it was
>> simpler/easier to just send all events and let the client do the masking if it
>> wants to. Later on, Daniel commented that it would be useful to able to mask
>> events early on.. Now, this proposal will require registration.
>>
>> We don't seem to make our mind..
>>
>> Daniel, what do you think?
>>      
> I've always thought it was bad to have all events enabled all
> the time, because it is not scalable as the number&  frequency
> of events increases. Requiring the app register for each event
> it cares about is more scalable&  also allows the app to discover
> if a particular event is actually supported by that QEMU version.
>    

Exactly.

> eg The initial 'qmp_capabilities' greeting from the client could
> include the list of all desired event names from the client,
> and the server could reply with the list of those event it can
> actually support&  has enabled.
>    

The trouble is that if we want to have events associated with particular 
objects, then this method doesn't really work well.

For instance, if we had some high frequency event for block drivers, I 
may want to register the event for a specific device only for a short 
period of time.

Having a simple mask/unmask global event doesn't really do that well.

I think a key to success in QMP is to make the API usable in QEMU and I 
think we need that ability for it to be useful in QEMU.

Regards,

Anthony Liguori
> Daniel
>