[Swan-dev] debug-logging

[Andrew Cagney]

To move this discussion along a little, I added the function(1):

    void dbg(const char *fmt, ...) PRINTF_LIKE(1);

and tried using it in "ikev2_tc.c" vis:

    dbg("    connection \"%s\" does not match IDs or CA of current
connection \"%s\"",
         d->name, c->name);

my idea is to next add:

   dbg_crypt()

and then dump DBGF().

Andrew

(1) the name is short; coding style dogma has lower case functions,
and upper case macros (the latter has to scream danger!), DBG() was
taken and I don't see this as a performance issue
On Wed, 17 Oct 2018 at 11:04, Andrew Cagney <andrew.cagney at gmail.com> wrote:
>
> These are my fuzzy notes from a group discussion from last week about
> debug-logging - that is dumping stuff we'd like to see when chasing a
> bug
>
> - '--debug all' current debug-log functions are controlled by debug
> bits, for instance a debug-log line, using the current simplest
> interface, looks like:
>     DBGF(DBG_XAUTH|DBG_KERNEL,
>         "this is debug-logged when either %s or %s is enabled",
>         "XAUTH", "kernel");
>   Unfortunately, over time, this model has broken down.  Instead
> debuglog=all has proven to be the only workable option.  Consequently,
> the flags should be dropped and the simplest interface further reduced
> to just:
>     DBGF("this is debug-logged when %s is enabled", "any debugging");
>  (name is subject to ongoing discussion). The obvious follow-on (not
> yet discussed) is that --debug all will need a re-name, --debug info
> --debug flow --debug default
>
> - '--debug private' - which is for end users and intentionally exposes
> security information - is really a system-log parameter so should be
> kicked out of --debug and moved somewhere else (presumably some other
> option)
>
> - '--debug crypt' - which unintentionally exposes security information
> and lots off it - should be retained and shouldn't be the default
>   presumably, debug-log messages such as 'computing DH' don't fall
> under 'crypt', but the actual calculations do
>
> - '--debug too-much-information' - sometimes too much irrelevant
> debug-log information is generated.  For instance, the hash table code
> debug-logs all transitions in great detail - something not useful
> except when debugging the hash table subsystem.  Rather then remove
> that code, a finer-grained logging interface is also needed (and not
> enabled by default).  For instance:
>     DBG_FINE("this will probably never be debug-logged");
>   (name is subject to ongoing discussion)
>
> my comments:
>
> - I subscribe to the dogma that all macros should be upper case
>
> - unless we're pretty aggressive over what gets moved to 'fine', I
> suspect we'll end up needing a way to debug-log less than the default
> set or adding more fine-grained bits similar to 'crypt'
>   for instance, the raw contents of every packet gets dumped on the
> way in; should it?
>
> - code generating a single log line such as:
>     DBG(DBG_KERNEL|DBG_XAUTH, DBG_log("...", ...));
>   and can be reduced to:
>    DBGF("...", ...);
>
> Andrew