On 31/01/2017 14:45, Ed Swierk wrote:
> When a serial port writes data to a pty that's disconnected, drop the
> data and return the length dropped. This avoids triggering pointless
> retries in callers like the 16550A serial_xmit(), and causes
> qemu_chr_fe_write() to write all data to the log fi
On 31/01/2017 14:19, Ed Swierk wrote:
> Either way, when a pty is disconnected data will get dropped, whether
> by the pty backend (as proposed) or by the serial port device or other
> frontend (as currently).
>
> The only difference from a user's perspective is whether the dropped
> data gets w
On Tue, Jan 31, 2017 at 6:06 AM, Marc-André Lureau wrote:
> I think this can be confusing if some backends silently drop the data (under
> disconnected state), while other don't. Perhaps we should have instead a new
> common chardev property "hup-drop" ? (suggestions for better name welcome)
Ei
Hi
- Original Message -
> Hi
>
> - Original Message -
> > When a serial port writes data to a pty that's disconnected, drop the
> > data and return the length dropped. This avoids triggering pointless
> > retries in callers like the 16550A serial_xmit(), and causes
> > qemu_chr_fe
Hi
- Original Message -
> When a serial port writes data to a pty that's disconnected, drop the
> data and return the length dropped. This avoids triggering pointless
> retries in callers like the 16550A serial_xmit(), and causes
> qemu_chr_fe_write() to write all data to the log file, rat
When a serial port writes data to a pty that's disconnected, drop the
data and return the length dropped. This avoids triggering pointless
retries in callers like the 16550A serial_xmit(), and causes
qemu_chr_fe_write() to write all data to the log file, rather than
logging only while a pty client
