From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOYZa-0001VW-4Q for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:56:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOYZV-0001KY-BE for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:56:37 -0400 Received: from [199.232.76.173] (port=56096 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOYZV-0001KK-3k for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:56:33 -0400 Received: from mx2.redhat.com ([66.187.237.31]:54315) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOYZU-0000HF-KH for qemu-devel@nongnu.org; Wed, 08 Jul 2009 10:56:32 -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 n68EuVGq032176 for ; Wed, 8 Jul 2009 10:56:31 -0400 Subject: Re: [Qemu-devel] [PATCH 0/3] Allow host_net_add monitor command accept file descriptors From: Mark McLoughlin In-Reply-To: <20090707100630.GA24595@redhat.com> References: <1246901401.12086.20.camel@blaa> <4A52DD05.9030007@redhat.com> <1246952623.2836.13.camel@blaa> <4A52FED7.4090800@redhat.com> <1246954387.2836.30.camel@blaa> <4A530F56.4060101@redhat.com> <20090707100630.GA24595@redhat.com> Content-Type: text/plain Date: Wed, 08 Jul 2009 15:56:03 +0100 Message-Id: <1247064963.3270.63.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Avi Kivity , qemu-devel On Tue, 2009-07-07 at 11:06 +0100, Daniel P. Berrange wrote: > On Tue, Jul 07, 2009 at 12:03:18PM +0300, Avi Kivity wrote: > > 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. > > I must say the idea of being able to pass a FD for migration would be > very nice. We currently have to open a localhost TCP port and tell QEMU > to connect to is, which is less than desirable for security since we > cannot guarentee the process we want is the one actually connecting. Okay, I'm sold - following up with a version with getfd/closefd. Cheers, Mark.