From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTWtr-0003CQ-5W for qemu-devel@nongnu.org; Wed, 22 Jul 2009 04:10:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTWtm-0003CE-Un for qemu-devel@nongnu.org; Wed, 22 Jul 2009 04:10:06 -0400 Received: from [199.232.76.173] (port=57263 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTWtm-0003CB-QZ for qemu-devel@nongnu.org; Wed, 22 Jul 2009 04:10:02 -0400 Received: from mx20.gnu.org ([199.232.41.8]:15138) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTWtm-0002Xs-9y for qemu-devel@nongnu.org; Wed, 22 Jul 2009 04:10:02 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTWtk-0000Ju-T5 for qemu-devel@nongnu.org; Wed, 22 Jul 2009 04:10:01 -0400 Subject: Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands From: Mark McLoughlin In-Reply-To: <4A667780.5040803@codemonkey.ws> 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> <1248194411.7126.17.camel@blaa> <4A667780.5040803@codemonkey.ws> Content-Type: text/plain Date: Wed, 22 Jul 2009 09:09:29 +0100 Message-Id: <1248250169.2867.33.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: Anthony Liguori Cc: Avi Kivity , qemu-devel@nongnu.org On Tue, 2009-07-21 at 21:20 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > 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 think there's a subtle point that was lost in the thread. While we'll > only need to queue one fd per MonitorState, we'll still need to deal > with multiple fds per CharDriverState. Why? For a theoretical use case, or for the current monitor interface? If the latter, then I don't follow. The flow is as follows: client server ------ ------ send request -> wait for response read request process msgfd, allowing only a single fd monitor handles request <- send reply handle response close msgfd if unused send next request -> If the client sends multiple requests at once, it is broken - it must wait for a "(qemu) " reply before sending another request. If the client sends multiple fds in a single request, it is broken - no monitor commands support multiple fds. If the client is broken and sends multiple fds, we only read the first one and the kernel frees the others. If the client sends an fd along with a request which does not require an fd, we just close that fd after we've processed the request. If we get a new protocol which allows multiple requests per message or multiple fds per request, we can easily add a queue then. Cheers, Mark.