From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4cl-0005Yb-8V for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:00:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn4cf-0005m7-CT for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:00:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn4cf-0005lx-2e for qemu-devel@nongnu.org; Fri, 16 Oct 2015 09:00:37 -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> <5620F213.1010908@redhat.com> From: Paolo Bonzini Message-ID: <5620F4EF.1070300@redhat.com> Date: Fri, 16 Oct 2015 15:00:31 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] What's the intended use of log.h logging? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Pavel Butsykin , Markus Armbruster , QEMU Developers , Luiz Capitulino , Stefan Hajnoczi , "Denis V. Lunev" On 16/10/2015 14:54, Peter Maydell wrote: > On 16 October 2015 at 13:48, Paolo Bonzini wrote: >> >> >> On 16/10/2015 14:33, Markus Armbruster wrote: >>> Looks like this is basically TCG with a couple of random LOG_UNIMP >>> and LOG_GUEST_ERROR thrown in. It's definitely not a general purp= ose >>> QEMU log in its current state. >> >> I think these could become error_report. >=20 > No; it's important not to print these unless the user really > asked for them (especially the GUEST_ERROR) kind. Otherwise it's > (potentially quite a lot of) unnecessary noise. I guess it depends then. If the unimplemented feature is in all likelihood a showstopper (e.g. setend) it should be unconditionally enabled, I think. >> Some others (e.g. LOG_IOPORT) can be removed. >> >> LOG_MMU seems to be mostly a ppc thing, could also become a tracepoint= . >> Likewise for LOG_PCALL and perhaps LOG_INT. >=20 > It's also very useful to be able to enable whole *classes* of > tracing (like "tell me whenever my guest OS does something dumb"); > does the tracepoint code have any support for this? That's part of what I mentioned in my message ("add some functionality to enable tracepoints more easily"). It would be great to have something like "-d trace:scsi_*" on the command line, integrated with qemu-log. So perhaps the place of qemu-log is as a replacement for the stderr tracing backend? Paolo