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
