Gerd Hoffmann wrote:
On 04/08/09 16:33, Daniel P. Berrange wrote:
On Wed, Apr 08, 2009 at 09:16:43AM -0500, Anthony Liguori wrote:
The wait command will pause the monitor the command was issued in
until a new
event becomes available. Events are queued if there isn't a waiter
present.
The wait command completes after a single event is available.
Today, we queue events indefinitely but in the future, I suspect
we'll drop
events that are older than a certain amount of time to avoid infinitely
allocating memory for long running VMs.
To make use of the new notification mechanism, this patch introduces a
qemu_notify_event() API. This API takes three parameters: a class
which is
meant to classify the type of event being generated, a name which is
meant to
distinguish which event in the class that has been generated, and a
details
parameters which is meant to allow events to send arbitrary data
with a given
event.
Perhaps we should have the ability to turn on/off events, via a
'notify EVENT'
command, and a way turn off the prompt on the channel used for receiving
events.
That would nicely solve the "queue events indefinitely" issue. By
default no events are generated. Apps which want receive them (and
thus receive them) can enable them as needed.
It doesn't. When an app enables events, we would start queuing them,
but if it didn't consume them in a timely manner (or at all), we would
start leaking memory badly.
We want to be robust even in the face of poorly written management
apps/scripts so we need some expiration function too.
And then in the 2nd monitor channel, a single 'wait' command would turn
off the monitor prompt and make the channel dedicated for just events,
one per line
(qemu) wait
rtc-change UTC+0100
vnc-client connect 192.46.12.4:9353
vnc-client disconnect 192.46.12.4:9353
vnc-client connect 192.46.12.2:9353
vnc-client disconnect 192.46.12.2:9353
IMHO this is more useful than having "wait" just get one event.
You'll need a dedicated monitor channel for events anyway, so with
one-event-per-wait the management app would have to issue wait in a loop.
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
want. For instance, libvirt may attach to a monitor and issue a 'wait
"vm-state vnc-events"' and I may have some wiz-bang app that wants to
connect on another monitor, and issue a 'wait "watchdog-events"'. My
super-deluxe app may sit watching for watchdog events to do some sort of
fancy RAS stuff or something like that.
The 'notify EVENT' model makes this difficult unless you have notify act
only on the current monitor session. Monitor "sessions" are ill-defined
though b/c of things like tcp:// reconnects so I wouldn't want to do that.
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)'.
That said, I can see a few advantages in the above model. Obviously,
the ability to read a large chunk of output and then parse multiple
events in a single round trip is a big positive. You could get that
with my syntax by sending multiple wait commands at once but that's a
bit hackish.
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.
BTW: "wait" is quite generic. Maybe we should name the commands
notify-*, i.e. have
Good point, I like wait_event personally.
Regards,
Anthony Liguori
notify-enable $class
notify-disable $class
notify-getevents
cheers,
Gerd
--
Regards,
Anthony Liguori
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list