[strongSwan-dev] [PATCH 0/3] Proposer error unifier for loggers

[Thomas Egerer]

Hello Martin,


> Thanks for your patchset, looks promising. 
Sounds good.

> I didn't fully understand your requirements for such unique IDs, but
> they of course might be helpful for different things.
I know charon gives you a great deal of options how to configure logging and I
can very well deal with them. But if you look at it from the perspective of
someone who does not know the internals of the ike-daemon or does not care
if a message comes from cfg facility with debug level 2 or kernel with debug
level 1 but only if this message indicates that he/she has to do something or
not, you might get my point. Having the hook then allows you for numbering
the messages as well as for prepending additional patterns (like inf, err,
emerg etc) based on the aforementioned database which can be individually
catagorized to ones needs.
Also for two messages originating from the identical source -- let's say they
contain format specifiers like %Y, %H etc -- might look different to an
untrained eye. This might sound a bit far fetched, but believe me, people will
not alwas notice the messages are actually identical. So instead of groping in
the dark if someone can give you a unique number that can be used to identify
the source of it makes resolving bugs a lot more easier (especially if they
are caused by misconfigurations).

> The question I'm asking is: do you need these IDs across multiple
> loggers, i.e. do we have to add this (a little exotic) unique ID
> parameter to all loggers?
No the IDs are not required across multiple loggers. Hiding the id from all
other loggers makes it even less intrusive than I thought (btw thanks for
calling it exotic, I think having made it an u_int64_t was a bit strong).

> What about extending the logger_t interface by an optional "vlog" method
> that takes the raw format string along with a va_list? This would allow
> your logger backend to create/map these unique IDs just for itself
> without letting other loggers bother with them, and then take
> appropriate actions.
If you are talking about something like the code that I've (hopefully)
attached to this mail, then we're on the same page. It's a much better
approach than my original idea.

>[...]
> 
> That approach would be a little more flexible, as we are not bound to an
> arbitrary 64-bit identifier, but can inspect the raw format string in
> the logging backend. Does that sound reasonable?
Full ack.

Regards, Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-POC-Use-vlog-if-available-to-allow-for-error-unifica.patch
Type: text/x-diff
Size: 2828 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130403/a36f47b8/attachment.patch>