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

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
> > (qemu) notify vnc on
> >
> > ... time passes, we want to allow members of group x to log in
> >
> > (qemu) vnc_set_acl group:x
> > OK
> > (qemu)
> > notification: vnc connect aliguori
> > (qemu)
> >
> > with a single monitor, we can be sure that the connect happened the 
> > vnc_set_acl.  If the notification arrives on a different session, we 
> > have no way of knowing that.
>
> Only because there isn't a time stamp associated with the completion 
> of the other monitor command.  And you can globally replace timestamp 
> with some sort of incrementing id that's associated with each 
> notification and command completion.

Sure, you can fix the problem, but why introduce it in the first place?

I understand the urge for a simple command/response, but introducing 
multiple sessions breaks the "simple" and introduces new problems.

> You'll need this to support multiple monitors even with your model.  

Can you explain why?  As far as I can tell, if you have async 
notifications, you can do everything from one monitor.

> IMHO, multiple monitors is a critical feature to support in the long 
> term.

Multiple monitors are nice to have (for developers), but I don't see 
them as critical.

> > > I expect that in the short term future, we'll have a non-human 
> > > monitor mode that allows commands to be asynchronous.
> >
> > Then let's defer this until then?  'wait' is not useful for humans, 
> > they won't be retyping 'wait' every time something happens.
>
> But wait is useful for management apps today.  A wait-forever, which 
> is already in the next series, is also useful for humans.  It may not 
> be a perfect interface, but it's a step in the right direction.  We 
> have time before the next release and I expect that we'll have a 
> non-human mode before then.

I disagree, I think requiring multiple sessions for controlling a single 
application is clumsy.  I can't think of one protocol which uses it.  I 
don't think IMAP requires multiple sessions (and I don't think commands 
from one session can affect the other, except through the mail store).

> > > What's the established practice?  Do you know of any protocol that 
> > > is line based that does notifications like this?
> >
> > I guess most MUDs?
>
> I've never used a MUD before, I think that qualifies as before my time 
> :-)

Well I haven't either.  Maybe time to start.

> > > IMAP IDLE is pretty close to "wait-forever".
> >
> > IMAP IDLE can be terminated by the client, and so does not require 
> > multiple sessions (though IMAP supports them).
>
> Most modern clients use multiple sessions.  If you look at IMAP, it 
> doesn't multiplex commands so multiple sessions are necessary to 
> maintain usefulness while performing a long running task.

But commands in one session don't affect others.

> Anyway, I think terminating a wait is a perfectly reasonable requirement.

It breaks you command/response, though.

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