From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lb0-00028u-UC for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:26:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3lav-0002cr-Id for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:26:34 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:47296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3lav-0002bK-9Z for qemu-devel@nongnu.org; Mon, 29 Jul 2013 07:26:29 -0400 Message-ID: <51F6515C.8040304@msgid.tls.msk.ru> Date: Mon, 29 Jul 2013 15:26:20 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <51D3BEBA.4080809@msgid.tls.msk.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] moving CHR_EVENT_OPEN out of BH broke echo for muxed mon List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Anthony Liguori , qemu-devel 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 wrote: >> Before >> >> commit bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec >> Author: Michael Roth >> 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 >> >