Back at Ericsson. :) On 12-01-31 06:19 PM, Mathieu Desnoyers wrote: > * Matthew Khouzam (matthew.khou...@ericsson.com) wrote: >> >> On 12-01-31 05:41 PM, Mathieu Desnoyers wrote: >>> Hi, >>> >>> Some early LTTng-UST adopters brought to my attention that the way >>> tracepoint loglevels are currently specified in LTTng-UST might be too >>> relax for its own good. If each application define their own loglevel >>> names/values, it will become difficult to use the loglevels to select >>> "trace verbosity" in a system-wide manner. >>> >>> Now that I come to think of it, it might make sense to pre-define a set >>> of supported loglevels, similarly to syslog(3). However, given that >>> tracing sometimes targets debug levels that are more fine-grained than >>> in the case of logs, I would propose to split the "debug" loglevel into >>> sub-categories. The following loglevel names are just ideas, and >>> feedback is very welcome. >>> >>> My current thought is to simply just allow these loglevels. I doubt that >>> letting application developers specify extra loglevels on top of this >>> would be that useful, and it would certainly be more confusing. >>> >>> In the list below, lower numbers means "low verbosity", higher numbers >>> means "high verbosity, debug-style information". >>> >>> based on syslog >>> http://linux.die.net/man/3/syslog >>> SUSv2 and POSIX.1-2001. POSIX.1-2001 >>> >>> TRACE_EMERG 0 >>> system is unusable >> Good >>> TRACE_ALERT 1 >>> action must be taken immediately >> How immediately? > As immediately as defined by syslog ;) levels 0 to 6, and TRACE_DEBUG, > are directly inspired from syslog(3), and so are their associated text. > > Having a too narrow description is probably not a good idea for > something as general as loglevels. > >>> TRACE_CRIT 2 >>> critical conditions >> Differentiate from alert please? to me critical sounds more critical. ;) > Derived from syslog. I guess they mean that a critical condition has > occured, but the system can still live for a while without human > intervention. > >>> TRACE_ERR 3 >>> error conditions >>> >>> TRACE_WARNING 4 >>> warning conditions >> classic combo >>> TRACE_NOTICE 5 >>> normal, but significant, condition >>> >>> TRACE_INFO 6 >>> informational message >>> > Starting from below, this is really for "tracing", not "logging". > >>> TRACE_SYSTEM 7 >>> information has system-level scope >> Could you have a system level error? I don't know, your app breaks >> OpenGL or something? > This is really not specifically limited to errors. This TRACE_SYSTEM > means: activate tracing data that helps understand what happens at the > system-level. > >>> 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 >>> >>> TRACE_PRINTF 14 >>> tracepoint_printf message >>> >>> TRACE_DEBUG 15 >>> debug-level message >> Are the trace levels in order of increasing threat? > At the top (0 to 6), yes, because they are derived from syslog. > > The rest are "tracing/debugging verbosity" levels. Ok, so I have a semi-clearer head. 0-6 is for loglevels, and this is called loglevel, I think it fits. 7-15 are tracing/debug level. Shouldn't they be in the domain? The issue I'm really not comfortable with is that we're comparing apples to durians here. We know a critical is more important than an info, but is a class more important than a notice? you change units half way through... if you wanted you could do something like a mask field so you can encode it all together ( trace_process == (1 << 8 ) .... then traceLevel = (TRACE_PROCESS | TRACE_CRITICAL). I still feel though that the loglevels should be loglevels, and the localizations should be in the domain.
>> I can see a slider >> showing up to level 7, but after they don't seem to fit in the advisory >> systems I've seen elsewhere. How would we choose which ones to activate? >> I am imagining an account manager going, "lets see the critical issues" >> "now the severe issues" "now the info" but then we go into more >> architectural stuff that may just confuse and make the tech support >> either ignore it, or activate everything. > Some will want to use tracing to get "log messages", others will want to > use it to gather very detailed debugging data on the applications. > Levels 7 to 15 fit in the second category. > > Basically, 7 to 15 are really the TRACE_DEBUG (last entry of syslog > loglevels) expanded to allow a much finer-grained selection of the trace > data. > >> Also, if I trace_printf something, couldn't it be a critical message? > I want the trace_printf statements to be kept for development-debugging > only, so I would rather prefer to make it the very last number, right > before the catch-all TRACE_DEBUG. 0 to 13, IMHO, only belong to > TRACEPOINT_EVENT declaration, not debug-style printf-alike ad-hoc > tracing. > >> I don't know, maybe I'm missing the point with the last ones. > Let me know if my explanation about the intent of expanding the DEBUG > level into multiple ones makes it clearer. > > Thanks for the feedback! > > Mathieu > >>> Thoughts ? >>> >>> Thanks, >>> >>> Mathieu >>> >>> _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
