[lttng-dev] [LTTng-UST RFC] Tracepoint Loglevels Specification

[Mathieu Desnoyers]

* Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> On 2012-01-31 17:41, Mathieu Desnoyers wrote:
> > Hi,
> >
> > TRACE_SYSTEM   7
> > information has system-level scope
> >
> > TRACE_PROCESS  8
> > information has process-level scope
> >
> > TRACE_MODULE   9
> > information has module (executable/library) scope
> >
> > TRACE_UNIT     10
> > information has compilation unit scope
> >
> > TRACE_CLASS    11
> > information has class-level scope
> >
> > TRACE_OBJECT   12
> > information has object-level scope
> >
> > TRACE_FUNCTION 13
> > information has function-level scope
> >
> First thought: I don't think that these levels (7-13) correspond to levels.
> These divisions sounds more like a part of the namespacing of the event
> and not level.

Reply to both Matthew and you:

When a specific problem requires more data to solve, then you can enable
the more detailed levels (between INFO and DEBUG) in a fine-grained
fashion, gathering more and more data as the investigation narrows down
the problem scope (so you can select more precisely which subset of the
tracing domain you are interested into).

I think wildcards and loglevels will nicely complement each other for
this kind of iterative investigation use-case. As you enable
finer-grained wildcards, you can afford to increase the loglevel
verbosity. But at the beginning of the investigation, you will typically
want to trace the whole world, but at a much less verbose loglevel.

The reason why I propose runtime/build entities for this more detailed
loglevel naming scheme is because the level at which someone thinks when
debugging a problem is that "I need to understand what is happening
within a process, so I will activate the process level", or "I need to
understand interaction between various programs across the system, so I
will enable system level".

Indeed, as we dig further down within a process, we have to use static
compile-time/link-time entities to specify a smaller granularity.

The reason why I propose these entities rather than more free-form
"major/minor" is because I think we really need to impose pre-defined
loglevels that will allow selection of verbosity across the entire
system (all applications) in a pre-defined way. If the semantic is too
loose, then we miss the ability to let users know what is happening when
they select "minor" instead of "major", because these identifiers do not
map to anything concrete for the user.

I changed the detailed part of the list this morning, removing "object"
and "class". New list:

 * TRACE_EMERG    0
 * system is unusable
 *
 * TRACE_ALERT    1
 * action must be taken immediately
 *
 * TRACE_CRIT     2
 * critical conditions
 *
 * TRACE_ERR      3
 * error conditions
 *
 * TRACE_WARNING  4
 * warning conditions
 *
 * TRACE_NOTICE   5
 * normal, but significant, condition
 *
 * TRACE_INFO     6
 * informational message
 *
 * TRACE_SYSTEM   7
 * information has system-level scope (set of programs)
 *
 * TRACE_PROGRAM  8
 * information has program-level scope (set of processes)
 *
 * TRACE_PROCESS  9
 * information has process-level scope (set of modules)
 *
 * TRACE_MODULE   10
 * information has module (executable/library) scope (set of units)
 *
 * TRACE_UNIT     11
 * information has compilation unit scope (set of functions)
 *
 * TRACE_FUNCTION 12
 * information has function-level scope
 *
 * TRACE_DEFAULT  13
 * default trace loglevel (TRACEPOINT_EVENT default)
 *
 * TRACE_VERBOSE  14
 * verbose information
 *
 * TRACE_DEBUG    15
 * debug-level message (trace_printf default)

Thoughts ?

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com