From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2W4v-000369-Nr for qemu-devel@nongnu.org; Mon, 26 Oct 2009 16:22:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2W4q-000354-J6 for qemu-devel@nongnu.org; Mon, 26 Oct 2009 16:22:08 -0400 Received: from [199.232.76.173] (port=55463 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2W4q-00034z-E6 for qemu-devel@nongnu.org; Mon, 26 Oct 2009 16:22:04 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:34239) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2W4p-00038Y-BH for qemu-devel@nongnu.org; Mon, 26 Oct 2009 16:22:04 -0400 Message-ID: <4AE6037D.4070100@web.de> Date: Mon, 26 Oct 2009 21:15:57 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 3/3] char: emit the OPENED event only when a new char connection is opened References: <1254920477-4645-1-git-send-email-amit.shah@redhat.com> <1254920477-4645-2-git-send-email-amit.shah@redhat.com> <1254920477-4645-3-git-send-email-amit.shah@redhat.com> <1254920477-4645-4-git-send-email-amit.shah@redhat.com> <4AE2D8C6.7070802@web.de> <20091026035312.GB11416@amit-x200.redhat.com> <4AE5525C.2040301@web.de> <20091026092841.GE11416@amit-x200.redhat.com> In-Reply-To: <20091026092841.GE11416@amit-x200.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig193AFEDBD933DD08634A32CE" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: Anthony Liguori , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig193AFEDBD933DD08634A32CE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Amit Shah wrote: > On (Mon) Oct 26 2009 [08:40:12], Jan Kiszka wrote: >> Amit Shah wrote: >>> On (Sat) Oct 24 2009 [12:36:54], Jan Kiszka wrote: >>>> Amit Shah wrote: >>>>> The OPENED event gets sent also when qemu resets its state initiall= y. >>>>> The consumers of the event aren't interested in receiving this even= t >>>>> on reset. >>>> The monitor was. Now its initial prompt on activation is broken. >>> The patch in Anthony's queue, titled >>> >>> 'console: call qemu_chr_reset() in text_console_init' >> You may also want to rename qemu_chr_reset - unless there is still a >> need for real "reset". >=20 > Yeah; there isn't a need after my patches -- I've been slowing working > towards renaming it all. >=20 >>> fixed that. >>> >>> However, with the qcow2 synchronous patch, the monitor prompt doesn't= >>> come up again -- which shows there is a problem with the way the bhs >>> work and also the initial resets. >> Then the qcow2 patch is already in? At least applying your patch doesn= 't >> change the picture. >=20 > Yeah; that patch went in just before my patches. Can you try reverting >=20 > ef845c3bf421290153154635dc18eaa677cecb43 Makes no difference either - but it also does not touch any code that code impact the open/reset signaling. >=20 >>> I think the initial resets are a hack to work around something from m= y >>> reading of it; do you have a better idea of why it's there and how it= 's >>> all supposed to work? >> From the monitor's POV, it's not a hack, it's simply the requirement t= o >> receive an indication that the console was opened. >=20 > Just an indication that the monitor was opened -- agreed. But git > history shows you added that as 'reset', so I'm wondering if maybe you > wanted it to do something else as well (or you did it that way just > because of the way qemu's bhs are handled?). I didn't add the reset hook for the monitor (it was Anthony), I just made some improvements. >=20 >>>> Does this patch fix/improve something for a different user? If not, >>>> please let us revert it. >>> There's another question too: is a separate 'reset' event needed in >>> addition to an 'opened' event? >> Not for the monitor, but I cannot speak for other users. I think it >> would be good to check them in details before changing the reset/open >> semantic. >=20 > As far as I could see in the git history, the 'reset' was added for the= > monitor. And the others could live with the double 'reset' events they > were getting -- one for the reset and one when the device was opened.=09 OK. However, the problems of your approach to avoid potential double resets on startup is that the supposed two events for the monitor (first one from qemu_chr_open_fs, second one via qemu_chr_initial_reset) actually coalesce into one, thus are never delivered. So whatever may happen later on, during startup the skipping of the first reset/open event is bogus. Jan --------------enig193AFEDBD933DD08634A32CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkrmA4IACgkQitSsb3rl5xS9CACfVC6AEdZ4KTnlso4W6QELKUm8 tdcAoKSS2SNiOklbcvzrfJvQ0Rb7s20N =0U7A -----END PGP SIGNATURE----- --------------enig193AFEDBD933DD08634A32CE--