|
| From: | Anthony Liguori |
| Subject: | Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command |
| Date: | Sat, 12 Mar 2011 17:30:10 -0600 |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 |
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
| [Prev in Thread] | Current Thread | [Next in Thread] |