From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:47236)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QGqVj-0007xr-5M
	for qemu-devel@nongnu.org; Mon, 02 May 2011 06:37:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QGqVi-0000F6-C1
	for qemu-devel@nongnu.org; Mon, 02 May 2011 06:37:51 -0400
Received: from fmmailgate03.web.de ([217.72.192.234]:52167)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1QGqVi-0000Et-1W
	for qemu-devel@nongnu.org; Mon, 02 May 2011 06:37:50 -0400
Message-ID: <4DBE8978.1030207@siemens.com>
Date: Mon, 02 May 2011 12:37:44 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1303979358-4421-1-git-send-email-alevy@redhat.com>	<1303979358-4421-4-git-send-email-alevy@redhat.com>	<4DBAAA92.60409@redhat.com>
	<20110429221944.GD13837@amber.local>	<4DBE731E.1050905@redhat.com>	<20110502101200.GG17629@playa.redhat.com>	<4DBE869A.4010403@redhat.com>
	<20110502103315.GA3633@playa.tlv.redhat.com>
In-Reply-To: <20110502103315.GA3633@playa.tlv.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: jan.kiszka@siemens.com
Subject: Re: [Qemu-devel] debug 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: Gerd Hoffmann <kraxel@redhat.com>, Alon Levy <alevy@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

On 2011-05-02 12:33, Alon Levy wrote:
> On Mon, May 02, 2011 at 12:25:30PM +0200, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> dbg_print takes care of making it standard to have a loglevel and prefix, sounds
>>> good, but I'd still like to know if it is acceptable to also redirect with -debug,
>>> I guess reusing the DeviceState then, instead of my added struct, so just letting
>>> DeviceState.debug_chardev == NULL by default, and settable with
>>> -debug<devname>,id=<chardev_id>
>>
>> Making dbg_print use DeviceState.debug_chardev (if present, stderr
>> otherwise) looks sane to me.  Buf I'd use standard properties then
>> to set it instead of a separate -debug switch, i.e.
>>
>>   -chardev file,id=messages,path=... \
>>   -device foo,dbg=1,dbglog=messages
>>
> 
> Sounds good. I'll try to make it so.

We have a tracing infrastructure for such use cases today. Better invest
in adding missing features there.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux