[libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
kraxel at redhat.com
Thu Apr 9 09:44:48 UTC 2009
On 04/08/09 19:44, Anthony Liguori wrote:
> We want to be robust even in the face of poorly written management
> apps/scripts so we need some expiration function too.
Well, if you want protect against broken apps, then yes, you'll have to
expire events ...
> There two issues with this syntax. The first is that 'notify EVENT'
> logically acts on the global event set. That's not necessarily what you
OK, having per-monitor events certainly makes sense.
> The second issue is that there is no clear way to deliminate events
> other than a new line. If we wanted to send data along with events, we
> really want to be able to span multiple lines. Especially if we want
> that data to be in the same format as some of the existing monitor
> commands. You could get around this by introducing a new deliminator
> like '.' but everyone can already handle '(qemu)'.
> Also, I think where the above really shines is if you're a human user
> and you want to see all the events while debugging. You really don't
> want to keep typing wait in the monitor.
> So as a compromise, I think we need to introduce a mode where we can do
> the above but I'd like to wait until after the first round of these go
> in. I'm thinking along the lines of 'wait N' where N can be -1 to
> signify an unlimited number of events or something like that.
Hmm. Why would you want to use -- say -- "wait 3" ? It probably will
be either "loop forever" or "single event" mode in practice. We might
also have a "single event, but don't block if there isn't any" mode.
More information about the libvir-list