[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote:
Anthony Liguori wrote:
> Right now only one monitor device can be enabled at a time. In order
> to support
> asynchronous notification of events, I would like to introduce a
> 'wait' command
> that waits for an event to occur. This implies that we need an
> additional
> monitor session to allow commands to still be executed while waiting
> for an
> asynchronous notification.
>
>
I think this is race prone. For example:
monitor 1: wait
monitor 2: hotunplug dev1
monitor 2: hotplug dev1
monitor 1: event
there is no way to tell whether event (which relates to dev1) happened
the hotunplug or after the hotunplug. In general there is no way to
correlate events to commands.
events don't correlate to commands. Can you give an example of why
you'd want to correlate and event to a command.
What's wrong with having async notifications?
Isn't this async notifications?
Sure, we'll need to make sure notifications don't mix with
command
responses, and that all commands are acked (the (qemu) prompt serves
that purpose now), but it seems to me do be a lot easier for the
management end.
FWIW, you can have asynchronous completion of monitor commands. See
migration as an example. The (qemu) prompt is the ack that the command
is finished. You can only have one async command per monitor session
which is why you need multiple monitors.
If we had a non-human monitor mode, I think it would be fine to have
many monitors multiplexed over a single channel. The internal monitor
abstraction doesn't change.
I think multiplexing multiple monitor sessions requires a non-human mode
because you need to tag all output, etc. which is what we need for
non-human mode anyway.
--
Regards,
Anthony Liguori