From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1OBPz9-0008Uo-Px for qemu-devel@nongnu.org; Mon, 10 May 2010 06:13:15 -0400 Received: from [140.186.70.92] (port=46434 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBPz3-0008R4-0p for qemu-devel@nongnu.org; Mon, 10 May 2010 06:13:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBPyv-0001Oc-Jf for qemu-devel@nongnu.org; Mon, 10 May 2010 06:13:08 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:47082) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBPyv-0001Nw-6J for qemu-devel@nongnu.org; Mon, 10 May 2010 06:13:01 -0400 Message-ID: <4BE7DC23.90100@web.de> Date: Mon, 10 May 2010 12:12:51 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Missing mon in monitor_cur_is_qmp() and qerror_report() References: <4BE48C48.5000100@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig97215A2223EF4DFAE372DAEA" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97215A2223EF4DFAE372DAEA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Markus Armbruster wrote: > Jan Kiszka writes: >=20 >> Luiz, >> >> I missed this when the API was first proposed: >> >> cur_mon is scheduled for removal (one day...). It's just an intermedia= te >> step to convert all users to explicit 'mon' passing. Thus, new APIs >> should not rely it. >> >> I just realized that monitor_cur_is_qmp() does so. It should be >> refactored to monitor_is_qmp(Monitor *mon). And qerror should be enhan= ce >> by a 'mon' argument as well. Callers that aren't passed a 'mon' >> themselves should either be fixed at this chance or could fall back to= >> cur_mon for the time being. >> >> So far for the theory - do you see any pitfalls in the existing usage?= >=20 > I put in the new uses of cur_mon, Luiz "only" ACKed them. >=20 > At any point in the program execution, we have one current monitor, or > none. Passing around the current monitor within monitor code is > workable, if somewhat tedious. But we need it not just in monitor code= , > we need it anywhere where we report errors. In other words, pretty muc= h > everywhere. Including places that do not and should not know about the= > monitor. Handing a monitor parameter down pretty much every call chain= > is beyond tedious, it's impractical. It's a process, but I don't think it's impractical per se. >=20 > The code reporting an error generally does not and should not know > anything about *how* the error gets communicated to the user. > Insulating it from that detail is proper separation of concerns, and > global variable cur_mon is my tool to get it. Good software > engineering. Like many powerful tools, global variables should be used= > sparingly and with care. I feel this use is well justified. >=20 > Instead of eliminating cur_mon, I'd like it to be hidden within > monitor.c. There are a few uses left outside it. If we start to allow cur_mon for error reporting, there is no reason not to convert monitor_printf back to where it came from. Back then we agreed on the current path. If we now decide to roll back, then let's make it consistently. But we already refactored quite a lot of code for explicit monitor passing... Jan PS: A patch for establishing monitor_is_qmp is in my queue. Holding it back for now until we agreed how to proceed. --------------enig97215A2223EF4DFAE372DAEA 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 iEYEARECAAYFAkvn3CcACgkQitSsb3rl5xT+uACfSIDrlwHrMZhZ8xuyXDq0AbR1 Hs0An3534PQLP5Bk20mo4r343Prk5Gi+ =1sVe -----END PGP SIGNATURE----- --------------enig97215A2223EF4DFAE372DAEA--