From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49059 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OgD95-0004ym-Cj
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 04:46:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kraxel@redhat.com>) id 1OgD94-0000Fr-0N
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 04:46:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:22666)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kraxel@redhat.com>) id 1OgD93-0000FE-Pr
	for qemu-devel@nongnu.org; Tue, 03 Aug 2010 04:46:45 -0400
Message-ID: <4C57D768.20401@redhat.com>
Date: Tue, 03 Aug 2010 10:46:32 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole
References: <1998763220.603051280770128553.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
	<4C5703A1.2040500@codemonkey.ws>
In-Reply-To: <4C5703A1.2040500@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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.nongnu.org/archive/html/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Amit Shah <amit.shah@redhat.com>, Anthony Liguori <aliguori@redhat.com>, Alon Levy <alevy@redhat.com>, qemu-devel <qemu-devel@nongnu.org>

   Hi,

> My main objection to ioctls is that you change states based on event
> delivery. This results in weird things like what happens when you do a
> chr_write while not ready or not connected.
>
> So what I'd rather see is a move to an API that was connection oriented.
> For instance, we could treat CharDriverState as an established
> connection. So something like:
>
> typedef struct CharServerState
> {
> int backlog; /* max simultaneous connections; -1 for unlimited */
> void (*connect)(CharServerState *s, CharDriverState *session);
> void (*disconnect)(CharServerState *s, CharDriverState *session);
> } CharDriverState;

Oh, that is a similar but unrelated issue.

We have open/close events on the *guest* side (i.e. some process inside 
the guests opens/closes /dev/vmchannel/org.qemu.foo.42).  This is what 
Alon wants to propagate from the device backend to the chardev.

We also have open/close (or connect/disconnect) events on the *host* 
side for the devices (or sockets) the chardevs are bound to.  This is 
what you are talking about.

Note that we already have events (CHR_EVENT_OPENED,CLOSED) for the host 
side.  Adding events for the guest side open/close events makes sense to 
me (and is certainly better than the ioctl patch).

cheers,
   Gerd