On Wed, 21 Nov 2018 at 00:54, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
