From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MObiE-0004Uk-H8 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:17:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MObiA-0004TW-Vb for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:17:46 -0400 Received: from [199.232.76.173] (port=56591 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MObiA-0004TP-PZ for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:17:42 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58621) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MObiA-0004M4-DZ for qemu-devel@nongnu.org; Wed, 08 Jul 2009 14:17:42 -0400 Message-ID: <4A54E2D3.3080005@redhat.com> Date: Wed, 08 Jul 2009 21:17:55 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] Add SCM_RIGHTS support to unix socket character devices 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> In-Reply-To: <4A54E146.4070806@codemonkey.ws> 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: Anthony Liguori Cc: Mark McLoughlin , qemu-devel@nongnu.org On 07/08/2009 09:11 PM, Anthony Liguori wrote: > Mark McLoughlin wrote: >> It only makes sense to have one per getfd command and ... > > It would be silly to pass many fds. fds are scarce resources and you > don't want to get into a position where you're queuing fds. If you issue N getfd commands, you've queued N fds. > If a management tool wants to send an fd, it should issue the monitor > command that needs the fd along with the fd via SCM_RIGHTS, and then > wait for that command to complete before issuing another command that > needs an fd. > 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.