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

[Matthew Khouzam]

Would you want to automate tracing of messages  too and then use
TRACE_MESSAGE_SEND/RECV and TRACE_ENTRY/EXIT style elements? Still not
sure if there's overlap with domain/marker/loglevels. This is a sincere
unironic but poorly constructed question.

On 12-02-02 10:56 AM, Mathieu Desnoyers wrote:
> * 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
>