qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/8] qemu-char: Automatically do fe_open / fe_cl


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 4/8] qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers
Date: Mon, 25 Mar 2013 07:46:31 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Hans de Goede <address@hidden> writes:

> 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.

Could we change virtio-serial to delay calling add_handlers so that we
could not introduce this variable?

Regards,

Anthony Liguori

>
> Signed-off-by: Hans de Goede <address@hidden>
> ---
>  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 4d565ba..0ddb081 100644
> --- a/hw/usb/redirect.c
> +++ b/hw/usb/redirect.c
> @@ -1310,7 +1310,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);
>  
> @@ -1334,7 +1333,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 8ef76e2..209ea38 100644
> --- a/hw/virtio-console.c
> +++ b/hw/virtio-console.c
> @@ -140,6 +140,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 554d72f..7c57971 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. */
> +        fe_open = 0;
>          ++s->avail_connections;
> +    } 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]