From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LUktf-0004LW-Ly
	for qemu-devel@nongnu.org; Wed, 04 Feb 2009 11:46:43 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LUkte-0004LG-57
	for qemu-devel@nongnu.org; Wed, 04 Feb 2009 11:46:43 -0500
Received: from [199.232.76.173] (port=42410 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LUktd-0004LD-W0
	for qemu-devel@nongnu.org; Wed, 04 Feb 2009 11:46:42 -0500
Received: from yw-out-1718.google.com ([74.125.46.152]:26255)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LUktd-0003KW-KU
	for qemu-devel@nongnu.org; Wed, 04 Feb 2009 11:46:41 -0500
Received: by yw-out-1718.google.com with SMTP id 6so1257312ywa.82
	for <qemu-devel@nongnu.org>; Wed, 04 Feb 2009 08:46:41 -0800 (PST)
Message-ID: <4989C65B.7070507@codemonkey.ws>
Date: Wed, 04 Feb 2009 10:46:19 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [patch 18/18] qemu: PCI device, disk and host network
	hot-add / hot-remove
References: <20090204133303.113145633@localhost.localdomain>	<20090204133924.976199377@localhost.localdomain>	<20090204143843.GA26946@redhat.com>	<4989B25F.6000100@codemonkey.ws>
	<4989BB69.1090300@redhat.com>
In-Reply-To: <4989BB69.1090300@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: qemu-devel@nongnu.org
Cc: Marcelo Tosatti <mtosatti@redhat.com>

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> It doesn't support this today but additional patches to enable that 
>> are certainly welcome.  The best way would be a generic mechanism to 
>> send a file descriptor to QEMU that could then be used anywhere fd= 
>> is valid.  For instance:
>>
>> (qemu) receivefd unix:foo.sock,server
>> fd=5
>> (qemu) closefd 5
>
> (qemu) receivefd myfd
> // qemu receives an fd over the monitor, and attaches it to the tag 
> 'myfd'

Completely reasonable, but it's going to be hard to implement in a way 
that doesn't suck.  You'll have to extend the character driver interface 
to support receiving file descriptors, plumb that appropriately through 
the monitor.

Seems like an odd abstraction to me though as unix domain sockets are 
the only transport that I know of that supports sending fds.

> (qemu) closefd myfd
> // qemu closes the fd attached to tag 'myfd'
>
> Advantages:
> - no runtime handshaking with a new socket
> - work with names, not numbers you need to read off the monitor

Names are fine.  I would have requested that the numbers be validated 
which require them to be tracked which makes them essentially names anyway.

Regards,

Anthony Liguori