From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47288)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZorI2-0001iA-5V
	for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:10:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZorHw-00031H-2X
	for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:10:42 -0400
Received: from relay.parallels.com ([195.214.232.42]:37123)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@openvz.org>) id 1ZorHv-00030k-OC
	for qemu-devel@nongnu.org; Wed, 21 Oct 2015 07:10:35 -0400
References: <1444894224-9542-1-git-send-email-den@openvz.org>
	<1444894224-9542-3-git-send-email-den@openvz.org>
	<87oafzdmck.fsf_-_@blackfin.pond.sub.org>
	<20151021104144.GC13408@stefanha-thinkpad.redhat.com>
From: "Denis V. Lunev" <den@openvz.org>
Message-ID: <56277294.1090208@openvz.org>
Date: Wed, 21 Oct 2015 14:10:12 +0300
MIME-Version: 1.0
In-Reply-To: <20151021104144.GC13408@stefanha-thinkpad.redhat.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] What's the intended use of log.h logging?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Pavel Butsykin <pbutsykin@virtuozzo.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On 10/21/2015 01:41 PM, Stefan Hajnoczi wrote:
> Two useful aspects for observability:
>
> 1. Logging
>
> Error messages, rate-limited warnings, and important troubleshooting
> information for users.
>
> Audience: Users, system administrators, developers
>
> 2. Tracing
>
> Internal state changes and events for performance analysis.
>
> Audience: Developers
>
>
> DPRINTF() falls under both #1 and #2.  Care needs to be taken to
> separate the logging from the tracing when converting DPRINTF().
>
> Side note: we don't have effect "once only" or rate-limiting built into
> error_report().  Guest-triggerable errors or warnings should be limited
> to prevent log flooding.
>
> It would be nice to unify TCG's "qemu log" and error_report() into a
> single logging mechanism that is thread-safe and has rate-limiting.
>
> Stefan
Sounds very good to me.

Short and simple.

Den