BIND 10 #735: Investigate BIND-9 Logging
BIND 10 Development
do-not-reply at isc.org
Tue Apr 26 13:47:20 UTC 2011
#735: Investigate BIND-9 Logging
-------------------------------------+-------------------------------------
Reporter: | Owner: UnAssigned
stephen | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20110503
critical | Resolution:
Component: | Sensitive: 0
Unclassified | Sub-Project: DNS
Keywords: | Estimated Difficulty: 4.0
Defect Severity: N/A | Total Hours: 0
Feature Depending on Ticket: |
logging |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by stephen):
* owner: stephen => UnAssigned
* status: assigned => reviewing
Comment:
The aim of this ticket was to assess whether the logging code used in BIND
9 could be used in BIND 10. In brief, I think we could use it and doing
so would be faster than writing our own system from scratch.
In more detail:
A comparison between the BIND 9 logging and the BIND 10 logging design has
been placed in [wiki:UsingBind9Logging]. This shows that there is a close
correspondence between the ideas of the two logging systems, enough for
the implementation to be possible without too much work.
To check this, some proof of concept (POC) code was implemented in the
branch experiments/stephen-bind9log (Latest commit
1a8cccd0bf7c43b281bd5ed6a7edf9131a2eb536. Note that some of the unit tests
fail because of the change in message format; as this was only POC code,
the tests were not updated.)
Specific issues and items that came up were:
* BIND 9 logging is part of libisc and depends fairly heavily on the rest
of it. Although it may be possible to extract only the logging code and
its dependencies from libisc, in practice the simplest thing to do was to
port the whole of libisc across. This proved fairly easy to do in the POC
implementation (the code can be found in src/lib/bind9), although some
macros that are created during "configure" were hard-coded; the BIND 10
configure script would need modification in a proper implementation.
* As noted in [wiki:UsingBind9Logging], the BIND 9 category corresponds to
the name of the BIND 10 logger, and the module to the program. In the
POC, the program name was taken to be the root logger name. When
initializing the logger, one-element "categories" and "modules" arrays
were dynamically created and used in setting up the BIND 9 logging for
that logger.
* BIND 10 loggers can be created and destroyed whereas in BIND 9, the
logging context for a module is created once during initialization. The
POC code stores the BIND 9 context in a static std::map associated with
logger name. When a logger is created it checks this map and retrieves
the existing context if present.
* The POC used the current BIND 10 structures to determine whether a
message is to be logged, instead of interrogating the BIND 9 data
structures. Although done to avoid changing too much code in the POC, on
reflection this should be retained; it would minimise the work required to
change the underlying implementation at some time in the future.
Some issues that remain to be resolved:
* libisc is part of BIND 9 at the moment (and stored in CVS). How would
BIND 10 keep up to date with changes in it?
* How would we handle customisations that we may want to do? (e.g. change
how the category and module are displayed in the message logged).
= Summary =
If we decide not to use a third-party package such as log4cxx, then using
the BIND 9 logging code in BIND 10 is definitely feasible. I think we
should try this before writing a logging system from scratch.
--
Ticket URL: <http://bind10.isc.org/ticket/735#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list