Patchwork [5/5] char: Equip the unix/tcp backend to handle nonblocking writes

login
register
mail settings
Submitter Amit Shah
Date Jan. 11, 2011, 11:10 a.m.
Message ID <2e63b173956da74c9759b57bddb9d2f01053f8b2.1294743490.git.amit.shah@redhat.com>
Download mbox | patch
Permalink /patch/78365/
State New
Headers show

Comments

Amit Shah - Jan. 11, 2011, 11:10 a.m.
Now that the infrastructure is in place to return -EAGAIN to callers,
individual char drivers can set their update_fd_handlers() function to
set or remove an fd's write handler.  This handler checks if the driver
became writable.

A generic callback routine is used for unblocking writes and letting
users of chardevs know that a driver became writable again.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 qemu-char.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
Paolo Bonzini - Jan. 11, 2011, 1:38 p.m.
On 01/11/2011 12:10 PM, Amit Shah wrote:
> +    char_set_fd_handlers(s->fd, tcp_chr_read_poll, tcp_chr_read,
> +                         char_write_unblocked, chr, poll_out);

Would the 4th parameter always be char_write_unblocked?  If so, what 
about making it hidden within char_set_fd_handlers (also because 
char_write_unblocked is static in qemu-char.c).

Paolo
Amit Shah - Jan. 12, 2011, 6:16 a.m.
On (Tue) Jan 11 2011 [14:38:00], Paolo Bonzini wrote:
> On 01/11/2011 12:10 PM, Amit Shah wrote:
> >+    char_set_fd_handlers(s->fd, tcp_chr_read_poll, tcp_chr_read,
> >+                         char_write_unblocked, chr, poll_out);
> 
> Would the 4th parameter always be char_write_unblocked?  If so, what
> about making it hidden within char_set_fd_handlers (also because
> char_write_unblocked is static in qemu-char.c).

It could change for other backends, but the plan is to move to a
struct-type declaration even for the fd handlers, like discussed in the
other thread with Gerd.

		Amit

Patch

diff --git a/qemu-char.c b/qemu-char.c
index 6e02334..55d442d 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -235,6 +235,19 @@  static int char_remove_fd_handlers(int fd)
     return qemu_set_fd_handler2(fd, NULL, NULL, NULL, NULL);
 }
 
+/*
+ * Generic routine that gets called when chardev becomes writable.
+ * Lets chardev user know it's OK to send more data.
+ */
+static void char_write_unblocked(void *opaque)
+{
+    CharDriverState *chr = opaque;
+
+    chr->write_blocked = false;
+    chr->update_fd_handlers(chr, false);
+    chr->chr_write_unblocked(chr->handler_opaque);
+}
+
 static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
 {
     return len;
@@ -2269,6 +2282,19 @@  static void tcp_chr_close(CharDriverState *chr)
     qemu_chr_event(chr, CHR_EVENT_CLOSED);
 }
 
+static void tcp_update_fd_handlers(CharDriverState *chr, bool poll_out)
+{
+    TCPCharDriver *s = chr->opaque;
+
+    /*
+     * This function is called only after tcp_chr_connect() is called
+     * (either in 'server' mode or client mode.  So we're sure of
+     * s->fd being initialised.
+     */
+    char_set_fd_handlers(s->fd, tcp_chr_read_poll, tcp_chr_read,
+                         char_write_unblocked, chr, poll_out);
+}
+
 static CharDriverState *qemu_chr_open_socket(QemuOpts *opts)
 {
     CharDriverState *chr = NULL;
@@ -2321,6 +2347,7 @@  static CharDriverState *qemu_chr_open_socket(QemuOpts *opts)
     chr->chr_write = tcp_chr_write;
     chr->chr_close = tcp_chr_close;
     chr->get_msgfd = tcp_get_msgfd;
+    chr->update_fd_handlers = tcp_update_fd_handlers;
 
     if (is_listen) {
         s->listen_fd = fd;