[Swan-dev] confread diagnostics [was: Re: [Swan-commit] Changes to ref refs/heads/master]

D. Hugh Redelmeier hugh at mimosa.com
Mon Jul 9 14:54:26 UTC 2018


| From: Andrew Cagney <andrew.cagney at gmail.com>
| Subject: Re: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master

It is useful to change the subject when replying to a commit message 
since those messages have totally non-descriptive and non-distinguishing 
subjects.

| Just pass in a stack allocated lswlog

I admit to not knowing enough about the new logging facilities.
I don't know if they are available in all the contexts in which
libipsecconf is or might be used.

I'm working towards understanding how libipsecconf handles
diagnostics.  I started by fixing what was clearly broken (as listed
in the commit message).

I prefer using stack allocation to heap allocation where a modest
bound can be put on the size of the object.  But right now I don't
know if there is a bound on the size of the list of diagnostics that
can be accumulated.  I'm pretty sure that the list can have more than
one diagnostic, something that doesn't match lswlog well (and isn't
reported well even with my changes).

One generic problem is that a lower level discovers problems but a
higher level knows the context needed to make a useful diagnostic.  So
observed errors need to be accumulated by the lower levels and
returned to the upper levels for reporting.  I think.

That problem was partially handled in Pluto by using the cur* global
variables and providing logging functions that pasted context on the
front of messages.

In libipsecconf, diagnostics don't really appear to follow a pattern
that makes sense to me.  Furthermore, I think that how logging should
be done (printf, fprintf to stderr, syslog) depends on something
really high and I suspect that that is being botched.

By adding starter_errors_t, I've provided a hook that will help fix this.  
This eventually should include using the lswlog stuff if possible.  For 
most of the code, starter_errors_t is opaque.  In particular, it could be 
changed to pass down context so the lower levels can actually log 
diagnostics themselves rather than passing them back for logging.


More information about the Swan-dev mailing list