* Yannick Brosseau ([email protected]) 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 _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
