From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTRRw-00030v-8u for qemu-devel@nongnu.org; Tue, 21 Jul 2009 22:20:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTRRr-000301-9v for qemu-devel@nongnu.org; Tue, 21 Jul 2009 22:20:55 -0400 Received: from [199.232.76.173] (port=36753 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTRRr-0002zy-4n for qemu-devel@nongnu.org; Tue, 21 Jul 2009 22:20:51 -0400 Received: from mail-yx0-f188.google.com ([209.85.210.188]:58378) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MTRRq-0005wv-Qi for qemu-devel@nongnu.org; Tue, 21 Jul 2009 22:20:50 -0400 Received: by yxe26 with SMTP id 26so5660639yxe.4 for ; Tue, 21 Jul 2009 19:20:50 -0700 (PDT) Message-ID: <4A667780.5040803@codemonkey.ws> Date: Tue, 21 Jul 2009 21:20:48 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/5] Add getfd and closefd monitor commands 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> In-Reply-To: <1248194411.7126.17.camel@blaa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Avi Kivity , qemu-devel@nongnu.org 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. I think the way this would most logically work would be a push interface verses a pull interface so that there wasn't double queuing. That is, whenever the CharDriverState gets an fd, it calls a function registered by the consumer of the CharDriverState. Regards, Anthony Liguori