[Qemu-devel] ui/gtk.c does not check qemu_chr_be_can_write()

[Qemu-devel] ui/gtk.c does not check qemu_chr_be_can_write()

[Michael Walle]

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?

-michael

Re: [Qemu-devel] ui/gtk.c does not check qemu_chr_be_can_write()

[Gerd Hoffmann]

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