Here's the current status.
The standard log primitive is:
log_message(RC_FLAGS, logger, FMT, ...)
where:
RC_FLAGS specifies:
whack's RC code; typically RC_LOG
which streams - WHACK, ERROR, LOG, DEBUG - to send message
(blank is equivalent to WHACK+LOG)
but unless something funky is going on, this is just RC_LOG
logger provides:
the context (prefix) for each message
a portal to whack (if whack is attached)
(There's a low-level LOG_JAMBUF() but lets ignore that)
and any code is expected to somehow specify the logging context, for instance:
log_message(RC_LOG, ike->sa.st_logger, "hi!");
log_message(RC_LOG, md->md_logger, "bye");
log_message(RC_LOG, pbsout->out_logger, "huh!");
but this is all very tedious, so there are wrappers for common cases:
log_state(RC_LOG, &ike->sa, "hi!");
This even works when standalone utilities call code expecting a
logger. For instance:
log_message(RC_LOG, ERROR_STREAM, "bad");
does-the-right-thing (the error appears on stderr with progname prepended).
So now some open discussion.
Yes log_message() is unwieldy (the name is because I needed something
unique and somewhat consistent):
- can log_message() be shortened?
It can't be log() as that is taken by the math library, but llog() or
(with irony) plog(), loglog() are now all free (or will be tomorrow)
- do we want wrappers, such as log_state(), or not?
I ask as I found, when updating code, that it was easier to just use
log_message() everywhere, even though it was longer
- can/should the convention where a struct logger field is always
called .logger be adopted?
So that log_message(RC_LOG, foo->logger, "logging foo") works; it
would violate .st_*.
- speaking of wrappers, what about loglog(O, MSG, ...) =>
log_message(RC_LOG, O->logger, MSG, ...) ....
The gaps:
-> what is with log_connection(rc_flags, logger, WHACKFD, c, ...); or
how come states have a logger but not the connection
Because it wasn't clear, at the time, if adding a logger to a
connection was useful. Turns out that most logging is against either
message digest or a state. For a connection it was typically
triggered by whack - hence whackfd - or via pending. Of course this
ignores:
- revival (yet again revival and pending appear in the same sentence)
- other exceptions
- just being consistent
So I'll likely end up adding a connection logger; mainly for consistency.
-> what is with code picking up the global logger such as
log_global(30), pexpect(450), passert(850), ...
Move along, nothing to see, ... too painful to replace ...
- but I want per-connection/per-state debugging to work again ...
The current theory is to add <<lset_t debug>> to <<struct logger>> and
then have dbg_message(logger, ....) test it
- is there 'something better'?
/* XXX: something better */
close_any(&st->st_logger->object_whackfd);
st->st_logger->object_whackfd = dup_any(logger->global_whackfd);
yes. Think about one whack adding a connection while a second is
trying to delete it.
- what about 'struct show'?
It's job is to suppress or add blank lines in show* output. I do
wonder about renaming it to 'struct whack', I'll keep wondering.
Andrew
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
