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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On 16 October 2015 at 13:33, Markus Armbruster <armbru@redhat.com> 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'.
> 
> I think the default is / has become wrong.  Easy enough to fix.
> 
> Let's compare log.h and tracing.
> 
> Both let you control stuff on the command line and in the monitor.
> 
> log.h's unit of control is a mask bit, which controls a canned group of
> related messages.
> 
> Tracing's unit of control is the individual message.  To control a group
> of messages, use globbing.  As long as we use sane names, this is
> strictly more powerful than canned group.  When you don't need the
> power, globbing can be harder to use than canned group with sensible
> names.

Hmm; I don't thinking globbing actually works that well here;
the naming scheme for tracing is a bit difficult since it's based
on function name, and the things you might want to trace a particular
behaviour are typically scattered a bit.
Having said that, the 'canned group' can be solved by some premade
cans of trace elements, although it would be nice to generate
those automatically.

> log.h can log to stderr, log to a file, or not log at all (default).
> 
> Tracing's capabilities depend on a compile time choice:
> 
> * You can pick multiple backends.  They're all simultaneously active.
>   If we want to support enabling configured backends selectively at
>   runtime, that shouldn't be hard.
> 
> * If you compile out tracing (configure only backend 'nop'), you can't
>   trace.  That's a feature.
> 
> * If you pick 'stderr', you can trace to stderr.  Turning it into a
>   backend that could alternatively trace to a file (-trace file=FNAME)
>   would be easy.  Picking just 'stderr' would be feature-equivalent to
>   log.h then.

Yes, that would be useful.

TBH the biggest problem I have with tracing is the flat name space and
the way it's all in one trace-events file/one header.  The names start
getting long/non-obvious quickly, and if you use them in lots of your
patches then bisecting gets really slow since every change causes 
recompilation of the entire code base due to the changed trace header.
I started looking at trying to split trace-events but it's non-trivial
since it's going to need to build multiple trace enums.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK