From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MO6Xv-00059P-NU for qemu-devel@nongnu.org; Tue, 07 Jul 2009 05:01:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MO6Xr-00057F-3y for qemu-devel@nongnu.org; Tue, 07 Jul 2009 05:01:03 -0400 Received: from [199.232.76.173] (port=41946 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MO6Xq-000578-Vg for qemu-devel@nongnu.org; Tue, 07 Jul 2009 05:00:59 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MO6Xq-0005Tb-AN for qemu-devel@nongnu.org; Tue, 07 Jul 2009 05:00:58 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6790uQT020805 for ; Tue, 7 Jul 2009 05:00:56 -0400 Message-ID: <4A530F56.4060101@redhat.com> Date: Tue, 07 Jul 2009 12:03:18 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] Allow host_net_add monitor command accept file descriptors References: <1246901401.12086.20.camel@blaa> <4A52DD05.9030007@redhat.com> <1246952623.2836.13.camel@blaa> <4A52FED7.4090800@redhat.com> <1246954387.2836.30.camel@blaa> In-Reply-To: <1246954387.2836.30.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: qemu-devel On 07/07/2009 11:13 AM, Mark McLoughlin wrote: >>> >>> Nice idea, certainly. >>> >>> However, since it's only currently useful for tap/socket networking, I'm >>> happier with not adding two new monitor commands and only supporting a >>> single fd for now. >>> >>> >> What happens when we do get more commands? >> > > Any specific ideas around what else might use it? > Migration, usb, passing around eventfds for interguest communication. >> Do we then add the new commands and special-case fd=msgfd ? >> > > Sounds like a fine plan to me. We could name an fd passed via the > current commands as "msgfd" and only the "getfd" command would have the > ability to assign another name. > If we can't see ahead, it's fine to accumulate cruft. When we can however we should avoid it. The external interfaces are complicated enough. -- error compiling committee.c: too many arguments to function