[Top] [All Lists]

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

Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices v2
From: Avi Kivity
Date: Sat, 11 Apr 2009 19:25:35 +0300
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
notification: vnc connect aliguori

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 

<Prev in Thread] Current Thread [Next in Thread>