[Swan-dev] debug-logging

[Andrew Cagney]

On Wed, 21 Nov 2018 at 00:54, Paul Wouters <paul at nohats.ca> wrote:
>
> On Tue, 20 Nov 2018, Andrew Cagney wrote:
>
> > While it works it heads for an interface explosion as we'll want at least:
> >     dbg_crypt()
> >     dbg_more()
> > So instead I'll repurpose DBGF() to be the more terse:
> >   DBGF(CRYPT, format, ...)
> >   DBGF(MORE, format, ...)
> > where both wrap a single dbgf(lset_t, format, ...) function.
>
>
> Less wrappers please? I'd prefer not to end up with 20 logging functions
> all wrapped onto 2 actually used logging functions?

I'll wrap DBG_log() instead.

> I thought we realised we have very few categories:
>
> 1) interactive log (eg to whack socket + system log)

two cases:

- whack only logging such as status queries
- whack+system logging

> 2) non-interactive log (only to system log)
> 3) regular debug log (eg what used to be debug-all)
> 4) private debug log (anything containing private key material or passwords)

two cases:
- the private logging (for some compliance stuff)
I was going to leave that as dbgf(private, ...)
- debug logging of crypto which, in all likelyhood leaks stuff, but
not intentionally

> 5) excessive log (really internal/developer-only should not be used normally logs)
- 'more' debug logging



> I dont mind if these 5 map to some others for simplicity, but so far I
> am seeing just more wrappers and functions, instead of less.

First we completely forgot to discuss eliminating cur_state,
cur_connection, and cur_port.  Presumably with log_state() et.al.?

Anyway, for debugging for the most part, dbg() is sufficient.  For
instance, this common case:
   DBG(DBG_CONTROL, DBG_log(....));
can be replaced by:
   dbg(...);
but I'm not about to rush out and change that everywhere - let it
happen organically.
(I also wish it was upper case but that's a lost cause).

However, this single function falls short in two ways:

- the raw DBG_*() functions such as DBG_dump() need to be 'wrapped'
in if-crypto and/or if-more et.al..  Current code solves this using:
   #1 DBG_cond_dump()
   #2 DBG(DBG_CONTROL, DBG_dump());
   #3 if (DBGP(DBG_CRYPTO)) DBG_dump();
My only plan here is to replace the very few case of #1 with #3 (it
doesn't suffer from #2s parsing problems).  I see no benefit in adding
DBG_crypt_dump() et.al.

- the output is long winded and/or complicated and better constructed
by accumulating it into a buffer - the most extreme example has to be
the snprintf() in fmt_common_shell_out() - this is where the lower
level lswlog*buf helps.  All the above, are wrappers to this.

> Note that I think these are the 5 kinds of logging, of which 3 are debug
> logging.
>
> There is still the issue of "very minimal logging" for very busy
> servers, which could be defined with a new keyword and only log
> messages of type ERROR.
>
> Paul