|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] RFC adding ioctl's to virtserial/virtconsole |
Date: | Tue, 03 Aug 2010 10:46:32 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100628 Red Hat/3.1-1.el6 Thunderbird/3.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |