Ondřej Kuzník wrote:
On Thu, Mar 05, 2020 at 04:06:42PM +0000, Howard Chu wrote:
> Just some initial thoughts on what a new logging daemon should do for us:
> The primary goal - we want to use a binary message format with as few format
conversions as possible between log
> sender and log processor.
> I'm thinking that we use message catalogs; we will need a tool to preprocess
> invocation in the source tree and replace them with a integer messageID. So at
> the messageID and the message parameters need to be sent, not any plaintext.
This might not work in the place of loadable modules where you have to
deal with many catalogs etc.
How about a different proposition, we use the message format char * as
the message id, potentially sending the text over the first time it's
used. This could still break if we unload a module and a new one is
loaded in its place, but that sounds fixable.
This sounds like we would need to keep track of which texts we've already sent, from
the caller's side.
We could alternatively just add another openlog() call in our module_load() handler,
to push over any module-specific messages. A catalog ID can be assigned to each module,
and prefixed to the individual message IDs being transmitted.
> ... that's what I have so far. It's a bit worrisome
because of the additional moving parts:
> message catalog creator, log server, log postprocessor. There's definitely more
> here, but most of it is moved out of the runtime hot path, which is the main goal.
Moving a lot of work to the log postprocessor is good.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/