Warning, debugging, and tracing

[Russ Allbery]

Both the new configuration file parser and the new tradindexed
implementation use warn() to report warning messages, so I'm planning on
going through all of the programs in INN and setting up the warn and die
handlers correctly, and probably converting a whole bunch of fprintfs to
calls to warn() or die().

Before doing that, though, I looked over what else was being used right
now, and there also seems to be a need, particularly in innd and nnrpd for
three other levels of reporting:

  * Notices about the course of normal operations (currently logged to
    syslog with L_NOTICE, which is at present LOG_WARNING).

  * Trace information and other optional logging, mostly the protocol
    traces in nnrpd.  Currently optionally logged to syslog with L_TRACE,
    which is at present LOG_DEBUG, in nnrpd.  innfeed uses d_printf
    instead for something similar, which can also be changed at runtime.

  * Pure debugging output.  Right now, lib/dbz.c has most of this with a
    DEBUG macro that's disabled by default.

So my current plan is to try to generalize message reporting to deal with
these cases as well.  My thoughts on this are to add three new functions:

  notice()      Normal operational information, default handler prints to
                stdout.  Stuff that the user generally wants to see but
                which isn't an error.

  trace()       Possibly verbose trace information, either tracing the
                protocol or tracing the code.  By default there is no
                handler, so everything sent to trace() is ignored, but
                that can be changed at run-time.

  debug()       Debugging information.  Not only without a handler by
                default, but by default (so far as it's possible), the
                calls to debug should just go away at compile time unless
                the code is compiled with -DDEBUG or something of that
                sort.

While I'm at it, I'll probably move all of this out into a separate
include file from libinn.h, probably inn/messages.h or the like.  Since I
want to avoid the doubled parentheses that lib/dbz.c uses for DEBUG,
making the debug invocation go away completely will probably only be
possible on platforms that support either C99 or GNU variadic macros
(detectable by configure), and on other platforms it will be a call to a
function that immediately returns unless INN is compiled with debugging.

How does this sound to everyone?  Right now, there's a mess of different
message reporting mechanisms going around, and I'd like to standardize on
one method across all of INN's routines.  That will let the main program
set the appropriate handlers, and all of the library routines just call
the reporting functions without having to worry about whether they're
invoked interactively or by a daemon.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.