qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peng Hao <peng.hao2@zte.com.cn>, marcandre.lureau@redhat.com
Cc: qemu-devel@nongnu.org, wang.yechao255@zte.com.cn,
	Daniel Berrange <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH V2] chardev: fix parallel device can't be reconnect
Date: Tue, 11 Jul 2017 10:30:14 +0200	[thread overview]
Message-ID: <d97e3209-e1d0-1c00-ae8b-7bb22eb198e2@redhat.com> (raw)
In-Reply-To: <1499773645-120137-1-git-send-email-peng.hao2@zte.com.cn>

On 11/07/2017 13:47, Peng Hao wrote:
> Parallel device don't register be->chr_can_read function, but remote
> disconnect event is handled in chr_read.So connected parallel device
> can not detect remote disconnect event. The chardevs with chr_can_read=NULL
> has the same problem.
> 
> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
> Reviewed-by: Wang Yechao <wang.yechao255@zte.com.cn>
> ---
>  chardev/char-socket.c  | 11 +++++++++++
>  chardev/char.c         | 10 ++++++++++
>  include/chardev/char.h |  9 +++++++++
>  3 files changed, 30 insertions(+)
> 
> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
> index ccc499c..aa44f8f 100644
> --- a/chardev/char-socket.c
> +++ b/chardev/char-socket.c
> @@ -139,6 +139,9 @@ static int tcp_chr_read_poll(void *opaque)
>          return 0;
>      }
>      s->max_size = qemu_chr_be_can_write(chr);
> +    if (qemu_chr_null_be_can_read(chr)) {
> +        return 1;
> +    }
>      return s->max_size;
>  }
>  
> @@ -422,6 +425,14 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque)
>      uint8_t buf[CHR_READ_BUF_LEN];
>      int len, size;
>  
> +    if (qemu_chr_null_be_can_read(chr)) {
> +        size = tcp_chr_recv(chr, (void *)buf, CHR_READ_BUF_LEN);

It would be better not to destroy data in the channel, because the
device could set handlers later.

Daniel, maybe QIOChannel could have a function to check for hung-up
channels and return a bool?  For file descriptors it would poll the file
descriptor and check for POLLHUP, while other channels would have a more
or less obvious implementation.

> +        if (size == 0 || size == -1) {
> +            tcp_chr_disconnect(chr);
> +        }
> +        return TRUE;
> +    }
> +
>      if (!s->connected || s->max_size <= 0) {
>          return TRUE;
>      }
> diff --git a/chardev/char.c b/chardev/char.c
> index 2b679a2..7f7f486 100644
> --- a/chardev/char.c
> +++ b/chardev/char.c
> @@ -148,6 +148,16 @@ int qemu_chr_write(Chardev *s, const uint8_t *buf, int len, bool write_all)
>      return offset;
>  }
>  
> +int qemu_chr_null_be_can_read(Chardev *s)
> +{
> +    CharBackend *be = s->be;
> +
> +    if (!be || !be->chr_can_read) {

I think it's really chr_read that you want to consider here.

Thanks,

Paolo

> +        return 1;
> +    }
> +    return 0;
> +}
> +
>  int qemu_chr_be_can_write(Chardev *s)
>  {
>      CharBackend *be = s->be;
> diff --git a/include/chardev/char.h b/include/chardev/char.h
> index 8a9ade4..8dd28a8 100644
> --- a/include/chardev/char.h
> +++ b/include/chardev/char.h
> @@ -114,6 +114,15 @@ void qemu_chr_cleanup(void);
>  Chardev *qemu_chr_new_noreplay(const char *label, const char *filename);
>  
>  /**
> + * @qemu_chr_null_be_can_read:
> + *
> + * Check if Chardev's chr_can_read is registered.
> + *
> + * Returns: 1 if Chardev's chr_can_read is null.
> + */
> +int qemu_chr_null_be_can_read(Chardev *s);
> +
> +/**
>   * @qemu_chr_be_can_write:
>   *
>   * Determine how much data the front end can currently accept.  This function
> 

  reply	other threads:[~2017-07-11  8:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 11:47 [Qemu-devel] [PATCH V2] chardev: fix parallel device can't be reconnect Peng Hao
2017-07-11  8:30 ` Paolo Bonzini [this message]
2017-07-11  9:15   ` Daniel P. Berrange
2017-07-11 12:21     ` Paolo Bonzini
2017-07-11 12:36       ` Marc-André Lureau
2017-07-11 12:37       ` Daniel P. Berrange
2017-07-11 12:40         ` Paolo Bonzini

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=d97e3209-e1d0-1c00-ae8b-7bb22eb198e2@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=peng.hao2@zte.com.cn \
    --cc=qemu-devel@nongnu.org \
    --cc=wang.yechao255@zte.com.cn \
    /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).