qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH


From: Peter Maydell
Subject: Re: [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event)
Date: Fri, 16 Oct 2015 13:51:30 +0100

On 16 October 2015 at 13:33, Markus Armbruster <address@hidden> wrote:
> We have a couple of related features, and I'd like to get some clarity
> on how exactly they should be used.
>
> 1. Tracing
>
>    Documented in docs/tracing.txt.
>
>    Each trace event can be individually controlled with -trace and with
>    monitor command trace-event.  Wildcards work.  Monitor command "info
>    trace-event" shows their status.
>
>    Supports a wealth of tracing backends: nop (compiles out tracing
>    completely), stderr (prints trace to stderr), "simple", "ftrace",
>    "dtrace", ...  Range from "trivially easy" to "complex power tool".

The major problem with this is it is a compile time choice
(especially the choice of backend), and our default backend
is 'nop'.

> 2. Ad hoc printing
>
>    We have 108 files with some #define DPRINTF(), and probably some more
>    sailing under different flags.  The ones that aren't useless should
>    probably be tracepoints.
>
> 3. "qemu/log.h" logging
>
>    Sports a "mask", where each bit enables a certain set of log
>    messages.  Control the mask with "-d item,..."  Try "-d help" to see
>    acceptable items.
>
>    Logs to stderr by default, can be redirected with "-D <logfile>".

This, though it is a bit ad-hoc, always exists, always behaves the
same way, and doesn't require anybody to rebuild QEMU to enable
tracing.

I think having a more consistent approach to logging would be great,
though.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]