[bind10-dev] Questions on the Logging API

[Michal 'vorner' Vaner]

Hello

On Fri, Dec 17, 2010 at 12:05:52PM +0000, Stephen Morris wrote:
> ... and a grep for MULQNAME will identify the section of code.  As the idea of symbolic names for the messages might be seen as too much like VMS or Windows, we could go for numeric identifiers, e.g.
> 
>    DLB1023:  a question section may have only one qname, packet received that has 6
> 
> However, aas we wouldn't want to use numeric values in the code, (DLB1023 is a lot less informative than DLB_MULQNAME), we would need some intermediate stage - grep for DLB1023 in the message files to get MULQNAME then grep for that. 

I vote for the symbolic ones instead of numbers, as you say, MULQNAME is much
easier to guess what it means than the number.

> The idea is that the messages are replaceable during the build process.  If a site does not supply a replacement message file, the original file supplied with the distribution is used.  And even if a replacement message file is supplied, it is merged with the distribution file, it does not replace it.  In this way, if we were to upgrade BIND and add new messages, BIND would still build with a message replacement file for the previous version even if it did generate warnings about some messages not being replaced.

Ah, so it wouldn't be possible to change the language just by configuration? It
does not seem really user friendly.

> We could do that, using dynamically loaded libraries. But we may want to look at it in other contexts (e.g. allowing a call-out to a user-written function to inspect a query received by the nameserver before passing it through for processing).

Yes, well, I expected that the messages are in files outside the binary code (so
we can change the language by configuration) and then it would need to be able
to handle multiple loaded files.

> OK, I see.  You are saying that you might want:
> 
>    MULQNAME: a question section may have only one qname, packet received that has 6
> 
> ... written to the log file but something like:
> 
>   { "id": "MULQNAME", "args": [6] }
> 
> ... written to a network port.
> 
> Yes, that is do-able...
> 
> Perhaps the most difficult part about it is packaging up the various types of arguments.  I would think that the easiest thing is to convert them all to strings at the point at which the message object (containing the condition code and arguments) is created.

Yes, that's what I meant.

> <message size><condition code><arg count><string1><\0><string2><\0>...
> 
> We would need to be disciplined though.  For the information to be interpreted with later versions of BIND-10, message numbers and meaning of arguments must not change.  So new messages should only be added to the end of the message file and messages that become unused are never removed.

Well, if it was in the log file directly, we could just skip the unknown ones.
But yes, we would have to never change the numbers (which we don't want anyway I
guess).

> I'm not sure what you mean when you say "the compiler could pick the messages out of the files by itself"?  It needs to know what to pick - which leads us back to the idea that each message has some unique identification.

Well, we could mark them somehow, like:
log.error(TRANSLATABLE(MULQNAME, "a question section may have only one qname, packet received that has %1"), 6);

And the message compiler would look trough the code to find TRANSLATABLE.

> The wiki article suggested that, putting the facility code into the most significant 16 bits and the error code into the least significant 16 bits.  So a single 32-bit number holds both bits of information. (In fact you can put a lot of information into a 32-bit number - see for example the information encoded into a VMS condition code -  http://h71000.www7.hp.com/doc/82final/5973/5973pro_022.html)

I probably missed that one in the article. But then, wouldn't it be better to
just have 2 parameters for the logging function? We don't need to compress it
that much (and if we wanted, we could have the parameters 16bit, but using
unsigned, no matter what it is on the platform, seems OK). I think it would be
more readable to write it that way and less error prone.

Have a nice day

-- 
There's the light at the end of the the Windows.
   -- Havlik Denis

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101217/a6807bb9/attachment.bin>