From: Hans de Goede <hdegoede@redhat.com>
To: qemu-devel@nongnu.org
Cc: Amit Shah <amit.shah@redhat.com>,
Hans de Goede <hdegoede@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: [Qemu-devel] [PATCH 04/11] qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers
Date: Tue, 26 Mar 2013 11:07:56 +0100 [thread overview]
Message-ID: <1364292483-16564-5-git-send-email-hdegoede@redhat.com> (raw)
In-Reply-To: <1364292483-16564-1-git-send-email-hdegoede@redhat.com>
Most frontends can't really determine if the guest actually has the frontend
side open. So lets automatically generate fe_open / fe_close as soon as a
frontend becomes ready (as signalled by calling qemu_chr_add_handlers) /
becomes non ready (as signalled by setting all handlers to NULL).
And allow frontends which can actually determine if the guest is listening to
opt-out of this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
hw/usb/redirect.c | 2 --
hw/virtio-console.c | 1 +
include/char/char.h | 1 +
qemu-char.c | 13 +++++++++++++
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 9734e42..d02a7b9 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -1282,7 +1282,6 @@ static int usbredir_initfn(USBDevice *udev)
dev->compatible_speedmask = USB_SPEED_MASK_FULL | USB_SPEED_MASK_HIGH;
/* Let the backend know we are ready */
- qemu_chr_fe_open(dev->cs);
qemu_chr_add_handlers(dev->cs, usbredir_chardev_can_read,
usbredir_chardev_read, usbredir_chardev_event, dev);
@@ -1306,7 +1305,6 @@ static void usbredir_handle_destroy(USBDevice *udev)
{
USBRedirDevice *dev = DO_UPCAST(USBRedirDevice, dev, udev);
- qemu_chr_fe_close(dev->cs);
qemu_chr_delete(dev->cs);
/* Note must be done after qemu_chr_close, as that causes a close event */
qemu_bh_delete(dev->chardev_close_bh);
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index e2d1c58..2f7c3df 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -131,6 +131,7 @@ static int virtconsole_initfn(VirtIOSerialPort *port)
}
if (vcon->chr) {
+ vcon->chr->explicit_fe_open = 1;
qemu_chr_add_handlers(vcon->chr, chr_can_read, chr_read, chr_event,
vcon);
}
diff --git a/include/char/char.h b/include/char/char.h
index 3174575..27ebbc3 100644
--- a/include/char/char.h
+++ b/include/char/char.h
@@ -76,6 +76,7 @@ struct CharDriverState {
char *filename;
int be_open;
int fe_open;
+ int explicit_fe_open;
int avail_connections;
QemuOpts *opts;
QTAILQ_ENTRY(CharDriverState) next;
diff --git a/qemu-char.c b/qemu-char.c
index 2f35504..f580297 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -194,9 +194,14 @@ void qemu_chr_add_handlers(CharDriverState *s,
IOEventHandler *fd_event,
void *opaque)
{
+ int fe_open;
+
if (!opaque && !fd_can_read && !fd_read && !fd_event) {
/* chr driver being released. */
++s->avail_connections;
+ fe_open = 0;
+ } else {
+ fe_open = 1;
}
s->chr_can_read = fd_can_read;
s->chr_read = fd_read;
@@ -205,6 +210,14 @@ void qemu_chr_add_handlers(CharDriverState *s,
if (s->chr_update_read_handler)
s->chr_update_read_handler(s);
+ if (!s->explicit_fe_open) {
+ if (fe_open) {
+ qemu_chr_fe_open(s);
+ } else {
+ qemu_chr_fe_close(s);
+ }
+ }
+
/* We're connecting to an already opened device, so let's make sure we
also get the open event */
if (s->be_open) {
--
1.8.1.4
next prev parent reply other threads:[~2013-03-26 10:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 10:07 [Qemu-devel] [PATCH 0/11] chardev frontend open handling cleanup v2 Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 01/11] qemu-char: Rename opened to be_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 02/11] qemu-char: Rename qemu_chr_generic_open to qemu_chr_be_generic_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 03/11] qemu-char: Add fe_open tracking Hans de Goede
2013-03-26 10:07 ` Hans de Goede [this message]
2013-03-26 10:07 ` [Qemu-devel] [PATCH 05/11] qemu-char: Cleanup: consolidate fe_open/fe_close into fe_set_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 06/11] qemu-char: Consolidate guest_close/guest_open into a set_fe_open callback Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 07/11] qemu-char: Move incrementing of avail_connections to qdev-properties-system Hans de Goede
2013-03-26 13:07 ` Paolo Bonzini
2013-03-26 13:30 ` Hans de Goede
2013-03-26 13:50 ` Paolo Bonzini
2013-03-27 14:09 ` Hans de Goede
2013-03-27 14:58 ` Paolo Bonzini
2013-03-27 15:16 ` Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 08/11] qemu-char: add_handlers: Don't re-send the be_open event on unregister Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 09/11] virtio-serial: Consolidate guest_open/guest_close into set_guest_connected Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 10/11] virtio-serial: propagate guest_connected to the port on post_load Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 11/11] spice-qemu-char: Drop hackish vmc_register on spice_chr_write Hans de Goede
2013-03-26 14:35 ` [Qemu-devel] [PATCH 0/11] chardev frontend open handling cleanup v2 Eric Blake
2013-03-27 21:15 ` Anthony Liguori
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=1364292483-16564-5-git-send-email-hdegoede@redhat.com \
--to=hdegoede@redhat.com \
--cc=amit.shah@redhat.com \
--cc=kraxel@redhat.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).