Can we try to fix this for 1.6 please? :)
Or should I try to cook up a patch?
Thanks,
/mjt
04.07.2013 01:06, Michael Roth wrote:
On Wed, Jul 3, 2013 at 1:03 AM, Michael Tokarev <m...@tls.msk.ru> wrote:
Before
commit bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec
Author: Michael Roth <mdr...@linux.vnet.ibm.com>
Date: Fri Jun 7 15:19:53 2013 -0500
qemu-char: don't issue CHR_EVENT_OPEN in a BH
we had no echo by default with -nographic, and it gave
the prompt when switching to monitor:
$ qemu-system-x86_64 -nographic
_
(nothing is on the screen except the command line)
(Ctrl+A, c)
QEMU 1.5.0 monitor - type 'help' for more information
(qemu) _
After this patch, we now have:
$ qemu-system-x86_64 -nographic
QEMU 1.5.0 monitor - type 'help' for more information
(qemu)
_
(note the cursor position on the _next_ line after the prompt),
and the system is actually in "serial port" mode, not monitor
mode (you still need to hit Ctrl+A,c to switch to monitor).
After a bit of unwinding I think I know what's going on.
When we attach a new front-end to a mux (via qemu_chr_add_handlers), we call the
mux_chr_update_read_handler() to take those new handlers and stick them in an
array of FEs.
We then switch over to the new FE by issuing CHR_EVENT_MUX_OUT to the
previously active FE (if there was one), updating our focus idx to be the
current FE count, and issuing CHR_EVENT_MUX_IN.
Then, finally, toward the end of qemu_chr_add_handlers(), we issue a
CHR_EVENT_OPENED if the backend is already open (true in the case of stdio).
Then we repeat this for subsequent FEs, which in the normal case results in
the monitor FE getting a CHR_EVENT_MUX_OUT shortly after.
- CHR_EVENT_MUX_IN prints the prompt if EVENT_OPENED has already been sent
- CHR_EVENT_OPENED causes the monitor to output the banner and initial prompt
- CHR_EVENT_MUX_OUT causes the monitor to print a newline (to delimit any
subsequent output from another FE.
Previously, due to CHR_EVENT_OPENED getting sent in a BH, the monitor FE
would've already gotten the MUX_OUT event, so the banner and initial prompt
would be buffered, and not sent till we switched back to the monitor. Now,
we sent CHR_EVENT_OPENED before the initial MUX_OUT, so the banner actually
gets display before we switch over to the next FE.
The start-up state is actually exactly what you'd see if you cycled once
through all the FEs in prior versions of QEMU, resulting in all this
buffered up output getting flushed.
Fix should be simple: defer CHR_EVENT_OPENED until after MUX_OUT to retain
the previous behavior. Gonna be out this week but can send a patch when I
get back.
Thanks for the catch.
Thanks,
/mjt
