qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Michael Walle <michael@walle.cc>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] ui/gtk.c does not check qemu_chr_be_can_write()
Date: Tue, 30 Sep 2014 10:45:28 +0200	[thread overview]
Message-ID: <1412066728.23471.11.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <66be66e8dfdeec976fc6c67c54cf587a@walle.cc>

On Mo, 2014-09-29 at 15:15 +0200, Michael Walle wrote:
> Hi Anthony, Hi Gerd,
> 
> the GTK frontend does not respect the the "chr_can_read" hook. The 
> frontend just writes characters to the device using qemu_chr_be_write() 
> without checking if the device can receive any input 
> (qemu_chr_be_can_write()).
> 
> At least for my device model (hw/char/milkymist-uart.c), this results in 
> an assertion because the rx callback asserts if there is already a 
> character in the buffer. It assumes that the uart_rx callback is only 
> called, if the uart_can_rx callback returns a value >0.
> 
> Do I make a wrong assumption here?

The assumption is correct, gtk should be fixed to not do that.

I'm not sure how to do that best though.  Most other chardevs just pass
on the qemu_chr_be_can_write return value in the poll handler (see
fd_chr_read_poll for example).  gtk gets the data from a vte widget
callback though, not a file handle which where we can decide to just not
read from unless we can actually forward the data to the backend ...

Guess we have to buffer the data and kick a timer in case our buffer is
not empty to flush it.

Better ideas anyone?

cheers,
  Gerd

      reply	other threads:[~2014-09-30  8:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29 13:15 [Qemu-devel] ui/gtk.c does not check qemu_chr_be_can_write() Michael Walle
2014-09-30  8:45 ` Gerd Hoffmann [this message]

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=1412066728.23471.11.camel@nilsson.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=michael@walle.cc \
    --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).