From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zldcb-0007Gz-MM for qemu-devel@nongnu.org; Mon, 12 Oct 2015 09:58:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZldcX-0000ay-Lv for qemu-devel@nongnu.org; Mon, 12 Oct 2015 09:58:37 -0400 Received: from relay.parallels.com ([195.214.232.42]:52630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZldcX-0000ao-DL for qemu-devel@nongnu.org; Mon, 12 Oct 2015 09:58:33 -0400 References: <1444639295-6588-1-git-send-email-den@openvz.org> <561BBA5C.6050505@redhat.com> From: "Denis V. Lunev" Message-ID: <561BBC7C.1020401@openvz.org> Date: Mon, 12 Oct 2015 16:58:20 +0300 MIME-Version: 1.0 In-Reply-To: <561BBA5C.6050505@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] log hmp/qmp command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Markus Armbruster , Luiz Capitulino , qemu-devel@nongnu.org, Pavel Butsykin On 10/12/2015 04:49 PM, Eric Blake wrote: > On 10/12/2015 02:41 AM, Denis V. Lunev wrote: >> From: Pavel Butsykin >> >> This log would be very welcome for long-term diagnostics of the system >> in the production. This log is at least necessary to understand what >> has been happened on the system and to identify issues at higher-level >> subsystems (libvirt, etc). >> >> Signed-off-by: Pavel Butsykin >> Signed-off-by: Denis V. Lunev >> CC: Markus Armbruster >> CC: Luiz Capitulino >> CC: Eric Blake >> --- >> @@ -3822,6 +3824,8 @@ static void handle_qmp_command(JSONMessageParser *parser, QList *tokens) >> error_setg(&local_err, QERR_JSON_PARSING); >> goto err_out; >> } >> + qemu_log_mask(LOG_CMD, "qmp \"%s\" requested\n", >> + qobject_to_json(obj)->string); >> > In addition to the leak already pointed out, qobject_to_json() can be > expensive, and it looks like we are doing that work unconditionally even > if the logging is not turned on. Is there a way to optimize so that the > conversion is only done when logging is enabled? > this seems quite reasonable. Will it be good if we'll change logging implementation to use macros, something like #define qemu_log_mask(int mask, const char *ftp, ...) \ do { \ va_list ap; \ \ if (!(qemu_loglevel & mask) || !qemu_logfile) {\ break;\ }\ qemu_log(ftp, __VA_ARGS__); \ } while (0) This IMHO makes sense even out of the scope of this patch. Den