| From: Andrew Cagney <[email protected]> | 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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
