Trace logging project

[Greg Hudson]

On Mon, 2009-09-14 at 19:15 -0400, Nicolas Williams wrote:
> I think it'd be great if you did define trace points as macros that
> could be generated by dtrace(1M).  Someone else could do the work of
> writing the .d file, autoconf and makefile code to use DTrace.

[Some out of band conversation ensues.]

Because the internal mechanism requires a context, there is an impedance
mismatch between USDT-style macros and what is needed for the internal
mechanism.  Also, we don't want our tracing calls to be mucking around
with converting data structures like krb5_principals into strings; that
needs to happen behind the covers (or perhaps not at all, for a USDT
provider).

As you noted, the most important thing is that there be some kind of
symbolic identification of the trace point.  That would come at the cost
of a big header file full of trace macro definitions, but it turns out
that Tom likes this idea anyway.  So I think the tracing calls will look
like:

  TRACE_GET_CREDS(context, in_creds->client, in_creds->server, options);

and then the basic macro in the big header file would read something
like:

  #define TRACE_GET_CREDS(c, client, server, flags) \
    k5trace(c, "Getting credentials for %P -> %P with flags %F",
            client, server, flags)

To add a USDT provider, one could add in a call to DTRACE_PROBE3 or to
an automatically-generated macro, perhaps after converting the arguments
to strings.  The changes might be a bit ugly if stringification is
included, but would be confined to a single header file.