Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole

[Gerd Hoffmann <kraxel@redhat.com>]

   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