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 thought we realised we have very few categories:
1) interactive log (eg to whack socket + system log)
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)
5) excessive log (really internal/developer-only should not be used normally
logs)
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.
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
