From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MTt60-0007Lg-3f
	for qemu-devel@nongnu.org; Thu, 23 Jul 2009 03:52:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MTt5w-0007LU-00
	for qemu-devel@nongnu.org; Thu, 23 Jul 2009 03:52:07 -0400
Received: from [199.232.76.173] (port=53024 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MTt5v-0007LR-QM
	for qemu-devel@nongnu.org; Thu, 23 Jul 2009 03:52:03 -0400
Received: from mx20.gnu.org ([199.232.41.8]:24036)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <markmc@redhat.com>) id 1MTt5u-0007NF-Hy
	for qemu-devel@nongnu.org; Thu, 23 Jul 2009 03:52:03 -0400
Received: from mx2.redhat.com ([66.187.237.31])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1MTt5t-0006Jq-Ok
	for qemu-devel@nongnu.org; Thu, 23 Jul 2009 03:52:02 -0400
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <4A680A87.7020100@web.de>
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> <1248250169.2867.33.camel@blaa>
	<4A680A87.7020100@web.de>
Content-Type: text/plain
Date: Thu, 23 Jul 2009 08:51:28 +0100
Message-Id: <1248335488.3067.19.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 3/5] Add getfd and closefd monitor commands
Reply-To: Mark McLoughlin <markmc@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org

On Thu, 2009-07-23 at 09:00 +0200, Jan Kiszka wrote:
> Mark McLoughlin wrote:
> > 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?
> > 
> 
> There can be multiple monitors attached at the same time, already today.

But each monitor has its own socket, CharDriverState and Monitor ...
multiple monitors is irrelevant to the need for an fd queue on
CharDriverState.

Cheers,
Mark.