Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

[Avi Kivity]

Anthony Liguori wrote:
> 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.

 hotplug disk
 -ENOSPC on disk

It's true that events don't correlate directly to commands, but they do 
correlate to the state of the system and that is affected by commands.


> > What's wrong with having async notifications?
>
> Isn't this async notifications?

I meant, on the good old single monitor.

> >   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.

Migration has the -d switch to be truly async (not to wait).  We need an 
async notifier to tell us migration has finished or failed.

If you go the multiple monitor route, you need one monitor per 
long-running command.  That way -> madness.  Moreover, having long 
running commands block implies there is no way to cancel them.

> 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 don't understand why we need to multiplex many monitors over one 
channel.  Let's keep one monitor, but with the ability to send 
notifications to the other end.

> 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.

I think this is orthogonal.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.