From: Gerd Hoffmann <kraxel@redhat.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: qemu list <qemu-devel@nongnu.org>, Paul Brook <paul@codesourcery.com>
Subject: [Qemu-devel] Re: [PATCH 2/5] char: Introduce char_set/remove_fd_handlers()
Date: Wed, 12 Jan 2011 10:11:23 +0100 [thread overview]
Message-ID: <4D2D703B.7040106@redhat.com> (raw)
In-Reply-To: <20110111172305.GB4092@amit-x200.redhat.com>
Hi,
>> Moving the handlers to a separate struct is clearly a incremental
>> cleanup which can follow later. Using enable/disable flags will
>> probably simplify the interfaces for the non-blocking mode and thus
>> simplify the whole patch series so I think this should be done now.
>
> Agree -- but it looks to be a big patch. I have some initial work done,
> and hence am not converting anything other than unix/tcp backends. The
> proposed interface here is local to this file, and just a couple of
> callers. No big deal to change it once this is in.
>
> (The struct for that will look like:
>
> struct fd_handler {
> int fd;
>
> IOHandler *read;
> IOHandler *write;
> IOCanReadHandler *read_poll;
>
> bool read_enabled, write_enabled, read_poll_enabled;
>
> void (*set_read_handler)(IOHandler *read_handler);
> void (*set_write_handler)(IOHandler *write_handler);
> void (*set_readpoll_handler)(IOCanReadHandler *read_poll_handler);
> }
No, that isn't what I have in mind ...
I'm thinking more about this:
(1) IOHandlerRecord gets variables to enable/disable the handlers
(a bunch of bools, a bitmask, whatever). They default to enabled
to maintain backward compatibility.
(2) One or more functions are added to enable/disable the handlers,
something like qemu_fd_check_read(int fd, bool enable);
(3) main_loop_wait() will check whenever the handler is actually
enabled before adding it to the file handle set for the select()
call.
This shouldn't be that big. And with this initial stuff in place you
can go forward with the non-blocking stuff. No need to pass around the
write handler or have callbacks just to enable/disable the checking for
a writable fd, the non-blocking code can just call
qemu_fd_check_write(fd, true/false) to do it.
Additional cleanups possible:
(1) switch everybody who registers/unregisters handlers to the new
enable/disable interface.
(2) move the function pointers from IOHandlerRecord to a separate
struct (say IOHandlerOps).
> Also: we also want to be able to select() on all fds so that we can
> detect disconnection events as they happen. So we also need an array
> somewhere.)
I think you can't do that without switching from select() to poll().
cheers,
Gerd
next prev parent reply other threads:[~2011-01-12 9:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 11:10 [Qemu-devel] [PATCH v9 0/5] char: Add support for nonblocking writes Amit Shah
2011-01-11 11:10 ` [Qemu-devel] [PATCH 1/5] char: Add a QemuChrHandlers struct to initialise chardev handlers Amit Shah
2011-01-11 14:17 ` [Qemu-devel] " Gerd Hoffmann
2011-01-11 17:13 ` [Qemu-devel] " Blue Swirl
2011-01-12 6:07 ` Amit Shah
2011-01-12 18:01 ` Michael Roth
2011-01-12 19:03 ` Blue Swirl
2011-01-13 6:14 ` Amit Shah
2011-01-13 21:29 ` Blue Swirl
2011-01-11 11:10 ` [Qemu-devel] [PATCH 2/5] char: Introduce char_set/remove_fd_handlers() Amit Shah
2011-01-11 14:39 ` [Qemu-devel] " Gerd Hoffmann
2011-01-11 15:38 ` Amit Shah
2011-01-11 15:54 ` Gerd Hoffmann
2011-01-11 17:23 ` Amit Shah
2011-01-12 9:11 ` Gerd Hoffmann [this message]
2011-01-11 11:10 ` [Qemu-devel] [PATCH 3/5] char: Add framework for a 'write unblocked' callback Amit Shah
2011-01-11 14:43 ` [Qemu-devel] " Gerd Hoffmann
2011-01-11 11:10 ` [Qemu-devel] [PATCH 4/5] char: Update send_all() to handle nonblocking chardev write requests Amit Shah
2011-01-11 11:10 ` [Qemu-devel] [PATCH 5/5] char: Equip the unix/tcp backend to handle nonblocking writes Amit Shah
2011-01-11 13:38 ` [Qemu-devel] " Paolo Bonzini
2011-01-12 6:16 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2D703B.7040106@redhat.com \
--to=kraxel@redhat.com \
--cc=amit.shah@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).