I was working on preparing this test case for the virt machine (I've been
using a test machine based around the exynos UART).
While looking at the uart code for the virt to find which serial peripheral
it uses (and the register layout), I noticed that the pl011
uart code calls qemu_chr_fe_accept_i
>
> > I don't think this works well enough: if the source isn't removed, but
> fd_can_read() returns 0, there is a potential busy loop on the next
> > fd_read().
>
This shouldn't happen. The sources all get set to non-blocking mode, the
only
blocking code is the poll itself. If fd_can_read() retu
On Fri, Jan 29, 2021 at 11:57 PM Iris Johnson wrote:
>
> Currently, the chardev backend code will prepare for IO polling to occur
> by potentially adding or removing a watch of the backing channel for the
> chardev. The chardev poll is added if the fd_can_read() function reports
> more than 0 byte
Currently, the chardev backend code will prepare for IO polling to occur
by potentially adding or removing a watch of the backing channel for the
chardev. The chardev poll is added if the fd_can_read() function reports
more than 0 byte of buffer space, if a poll handler is already setup and
the buf
