From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTIOT-0006PU-1L for qemu-devel@nongnu.org; Tue, 21 Jul 2009 12:40:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTIOO-0006PH-Ls for qemu-devel@nongnu.org; Tue, 21 Jul 2009 12:40:44 -0400 Received: from [199.232.76.173] (port=34706 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTIOO-0006PE-ED for qemu-devel@nongnu.org; Tue, 21 Jul 2009 12:40:40 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34530) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTION-0005IH-RT for qemu-devel@nongnu.org; Tue, 21 Jul 2009 12:40:40 -0400 Subject: Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands From: Mark McLoughlin In-Reply-To: <4A54F8F2.2080103@redhat.com> References: <1247064963.3270.63.camel@blaa> <1247065048-15706-1-git-send-email-markmc@redhat.com> <1247065048-15706-2-git-send-email-markmc@redhat.com> <1247065048-15706-3-git-send-email-markmc@redhat.com> <4A54BABD.3040903@redhat.com> <1247069035.3270.82.camel@blaa> <4A54C634.30007@redhat.com> <4A54E0B3.8090305@codemonkey.ws> <4A54E160.9000900@redhat.com> <4A54E3BC.40306@codemonkey.ws> <4A54E64E.8090100@redhat.com> <4A54EA7D.4040602@codemonkey.ws> <4A54F8F2.2080103@redhat.com> Content-Type: text/plain Date: Tue, 21 Jul 2009 17:40:11 +0100 Message-Id: <1248194411.7126.17.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org On Wed, 2009-07-08 at 22:52 +0300, Avi Kivity wrote: > On 07/08/2009 09:50 PM, Anthony Liguori wrote: > > Avi Kivity wrote: > >> If the client is written in a high level language it's also > >> reasonable that some buffering would take place and you'd see a > >> single packet containing multiple commands, or a command split into > >> multiple packets. Therefore I'd like to avoid any assumptions in > >> this area. > > > > That misses the point though. We process one command at a time in the > > monitor so we only need to buffer one fd at a time. When we start to > > process multiple commands at once in the monitor, we'll do so with > > multiple monitor states and we'll want to have one fd per monitor state. > > Again I'm thinking of the client. If two client threads issue commands > in parallel there'd be >1 fds on the wire. But qemu can consume them > sequentially so I agree queue may hold just a single fd. Okay, it sounds like these patches didn't get applied for 0.11 because of confusion over the conclusion here. My take on it is that we're all agreed that it's never valid with the current monitor protocol for a client to queue up multiple fds. It's a synchronous protocol, you can't send multiple commands at once. I'll re-post the patches in reply to this. Thanks, Mark.