From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lsg1e-0003Ia-AQ for qemu-devel@nongnu.org; Sat, 11 Apr 2009 12:25:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lsg1Z-0003FU-Gu for qemu-devel@nongnu.org; Sat, 11 Apr 2009 12:25:49 -0400 Received: from [199.232.76.173] (port=37942 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lsg1Z-0003FR-CB for qemu-devel@nongnu.org; Sat, 11 Apr 2009 12:25:45 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52247) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lsg1Y-0000jJ-UV for qemu-devel@nongnu.org; Sat, 11 Apr 2009 12:25:45 -0400 Message-ID: <49E0C47F.9070501@redhat.com> Date: Sat, 11 Apr 2009 19:25:35 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <49DDAF9F.7040400@redhat.com> <49DDF807.1050707@us.ibm.com> <49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com> <49DE0042.9050103@redhat.com> <49DE0271.8090103@us.ibm.com> <49DE05F2.5060304@redhat.com> <49DE0673.3070501@us.ibm.com> <49DE081D.1030702@redhat.com> <49DE0CF2.3060307@us.ibm.com> <49DE1029.3030909@redhat.com> <49DE16DE.6030206@us.ibm.com> <49DE1AD2.2060600@redhat.com> <49DE1DB3.30402@us.ibm.com> <49DE229B.7050408@redhat.com> <49DE2580.2030507@us.ibm.com> <49DE29C5.6010601@redhat.com> <49DE3321.4090900@us.ibm.com> In-Reply-To: <49DE3321.4090900@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard 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.