From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPRBh-0007av-Cu for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:15:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPRBc-0007Zu-F1 for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:15:36 -0400 Received: from [199.232.76.173] (port=37426 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPRBc-0007Zr-83 for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:15:32 -0400 Received: from mx20.gnu.org ([199.232.41.8]:57907) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPRBb-000238-U1 for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:15:32 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPRBb-0002Jf-5o for qemu-devel@nongnu.org; Fri, 10 Jul 2009 21:15:31 -0400 Date: Sat, 11 Jul 2009 02:15:29 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/5] Add SCM_RIGHTS support to unix socket character devices Message-ID: <20090711011529.GL30322@shareable.org> References: <1247064963.3270.63.camel@blaa> <1247065048-15706-1-git-send-email-markmc@redhat.com> <1247065048-15706-2-git-send-email-markmc@redhat.com> <4A54BA4D.4040809@redhat.com> <1247069043.3270.83.camel@blaa> <4A54E146.4070806@codemonkey.ws> <4A54E2D3.3080005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A54E2D3.3080005@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , qemu-devel@nongnu.org Avi Kivity wrote: > Why impose unnecessary restrictions? I agree that the guest shouldn't > use qemu as an fd store. But putting such limits in the code is laying > a trap for the client, which will show up in rare cases, for example two > client threads issuing unrelated getfd commands with the client author > not knowing it should serialize them. If there is an fd queue, then it clearly must be limited on the QEMU side to avoid becoming an fd store. A client issuing unrelated commands must be aware of that limitation. The queue length could be 1, or it could be 10 per monitor to allow some command overlap, but the client will need to be aware of it and limit overlap. That means the limit must be documented in any (future :-) monitor protocol documentation. -- Jamie