[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity
avi at redhat.com
Sat Apr 11 16:25:35 UTC 2009
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.
More information about the libvir-list
mailing list