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 >> every logging >> invocation in the source tree and replace them with a integer messageID. So >> at runtime only >> 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 complexity >> here, but most of it is moved out of the runtime hot path, which is the main >> goal. Suggestions? > > 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/
