From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34346)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1XErIP-00067c-Bv
	for qemu-devel@nongnu.org; Tue, 05 Aug 2014 22:49:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1XErIK-00075F-CB
	for qemu-devel@nongnu.org; Tue, 05 Aug 2014 22:49:45 -0400
Received: from mail-vc0-f182.google.com ([209.85.220.182]:59325)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.crosthwaite@petalogix.com>) id 1XErIK-00075B-8K
	for qemu-devel@nongnu.org; Tue, 05 Aug 2014 22:49:40 -0400
Received: by mail-vc0-f182.google.com with SMTP id hy4so3070890vcb.41
	for <qemu-devel@nongnu.org>; Tue, 05 Aug 2014 19:49:39 -0700 (PDT)
MIME-Version: 1.0
Sender: peter.crosthwaite@petalogix.com
In-Reply-To: <201408060923243574967@sangfor.com>
References: <201407251442088727201@sangfor.com> <874my5hh4s.fsf@linaro.org>
	<201407251907132706648@sangfor.com> <53D25991.3010001@suse.de>
	<201407261028057289331@sangfor.com> <53D7FB52.3080801@redhat.com>
	<CAJ75kXbisbQEg1S2RrLoa5D0Q0WULgAvFOp7B1=JSWb27ynuYg@mail.gmail.com>
	<CAEgOgz4=9a0xOQa=zRi69HE3ienKWoMRuBwc7nbB9Y8Xj9UGAA@mail.gmail.com>
	<201408060923243574967@sangfor.com>
Date: Wed, 6 Aug 2014 12:49:39 +1000
Message-ID: <CAEgOgz53p=Y+BAU41rucye2t_SQWrMt9_jUJzRSL8mr3z-dPVg@mail.gmail.com>
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [questions] about qemu log
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: Zhang Haoyu <zhanghy@sangfor.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>, William Dauchy <wdauchy@gmail.com>, =?UTF-8?B?QW5kcmVhc19Gw6RyYmVy?= <afaerber@suse.de>

On Wed, Aug 6, 2014 at 11:23 AM, Zhang Haoyu <zhanghy@sangfor.com> wrote:
>>>> The output is on qemu's stderr.  You are in control of what that stderr is.
>>>
>>> I don't get why we can configure
>>> -D /path/to/unique/file/name.log
>>>
>>> but we also have to redirect stderr (I didn't checked if the daemonize
>>> option was closing it). What's the purpose of this logfile option?
>>>
>>
>>Well -D will log to file only loggable (i.e. qemu_log()) information
>>(which has all sorts of options and switches). Stderr, is a little
>>more static and should in theory be limited to genuine errors. But if
>>you want a combined log of both you can simply omit -D to default
>>qemu_log output to stderr. This gives you a combined log that you can
>>redirect anywhere. To be honest, this is what I do as a matter of
>>course (2> foo rather than -D foo).
>>
> Maybe we can introduce a new qemu option to specify a error logfile where stderr be redirected, like below,
> DEF("elogfile", HAS_ARG, QEMU_OPTION_elogfile, \
>     "-elogfile logfile      redirect stderr log to logfile(default /var/log/qemu/<vm name>##.log)\n",
>     QEMU_ARCH_ALL)
> STEXI
> @item -elogfile @var{logfile}
> @findex -elogfile
> redirect stderr in @var{logfile}
> ETEXI
> then we can set the error log file through qemu command, /var/log/qemu/<vm name>##.log as default.
>

This sounds out-of-scope for QEMU to me and makes a standard flow
non-standard. If prints are going to stderr where should be going
elsewhere they probably should be fixed. Do you have specific examples
of information going to stderr that you would rather go to a log (be
it an error log or something else?).

Regards,
Peter

> Thanks,
> Zhang Haoyu
>
>>There's plently of tree wide work to clean up the cases where stderr
>>is used where qemu_log should be. If you are finding that log
>>information is going to stderr instead of the log, patches would be
>>welcome.
>>
>>Regards,
>>Peter
>
>