Trace logging project

[Greg Hudson]

On Mon, 2009-09-14 at 13:13 -0400, Nicolas Williams wrote:
> I would like this to see this requirement:
> 
>  - zero cost when tracing is disabled at build time
>  - only interesting events should be traceable, for a definition of
>    interesting (function entry/exit tracing is not interesting to me)

We agree.

As noted in the project page, the primary use case here is to help
experienced users (such as support staff) diagnose configuration
problems, not to aid programmers in debugging.  So, for instance, it's
important to know what preauth systems kinit tried to use or what KDC
was contacted for a TGS request.  Information at the level of function
calls is not important to this use case.

> Also, I think you should consider a DTrace USDT provider.

I will have to read up on this.

> Context initialization is interesting, and should be traceable without a
> context, for obvious reasons.

If the simple fact of context initialization is interesting, then that
can be traced just before krb5_init_context returns.

A more interesting question is whether we should trace profile reads,
since those are done with a profile handle instead of a krb5 context.
I'm not sure if those count as interesting events, though.

> > [...] littering the code base with tracing calls.
> 
> Ugh.  [...] I'd hate to see the
> code littered with trace macros/function calls in all function entries,
> before gotos, before returns.

I think my use of the word "littering" connoted more than I really
meant.