Hello,
At the risk of beating a dead horse and annoying you all
terribly much, I would like to submit some of my thinking
on a Hurd logging facility. Feel free to tear this to
shreads, but I think the discussion should be started
and work begun on a solution to the problem of what to
do about a hurd logging facility.
------------------------------------------------------
Proposal for a HURD logging facility
Jonathan S. Arney <[EMAIL PROTECTED]>
Comments and suggestions welcome.
GOAL:
To build a log daemon for the Hurd for the sake of keeping track
of hurd translator events such as filesystem errors, auth daemon
problems, or other information relating to the operation of hurd
daemons. In this way, users will be able to quote log messages
in the event of unusual failure conditions and provide more
meaningful bug reports.
DESIGN CONSTRAINTS:
*Lightweightness
A hurd logging facility must be lightweight, relying on as
little other functionality as possible.
*Simplicity
A hurd logging facility must be simple, allowing for some
configuration, but whose primary mode of operation should
be to log messages to a given port/file descriptor.
*Independence
If the logging facility is unable to perform its task to
log events, it must fail silently, not interfering with
the operations of the hurd. In this way, the hurd logging
facility may be entirely disabled without determent to the
operation of the system.
DESIGN:
This section describes an implementation of a hurd logging facility
which attempts to meet the above design goals and constraints.
This implementation consists of two components: a 'hurdlog' translator
and a hurd_logmsg function call. The 'hurdlog' translator will be
attached to '/servers/hurdlog' by default (although its operation
may be modified). The hurd_logmsg function call resides in 'libc'
and will attempt to attach to '/servers/hurdlog' by default when
logging messages.
RPC INTERFACE DESCRIPTION:
The following fragment describes the 'hurd_logmsg' RPC interface
using 'MIG' syntax. The first argument is the server port number
obtained from a path lookup of '/servers/hurdlog' or whatever
port the translator is attached to. The second parameter 'filename'
is a string containing the source filename of the party wishing
to make a log entry. The third parameter 'lineno' is the source
file line number of the party wishing to make a log entry. The third
parameter 'msg_type' is a priority or message type description. Its
possible values are the set {HURDLOG_DEBUG, HURDLOG_ERROR,
HURDLOG_WARNING}.
The final parameter 'error_text' is a string consisting of a message
determined by the caller of the RPC to be appended to the log entry.
routine hurd_logmsg(
klog_server: mach_port_t;
filename : string_t;
lineno : integer_t;
msg_type : integer_t;
error_text : string_t);
LOG TRANSLATOR:
The hurd log translator is built on top of 'libtrivfs' and provides a
single RPC called 'hurd_logmsg' as described in the interface
definition.
The mode of operation of the log translator is to open a file using the
'open' system call and to 'write' a message to it whenever the RPC is
invoked. The format of the log message is as follows:
date : filename[lineno] : error_text (newline)
In the event that the 'open' or 'write' functions fail, the translator
must ignore the results and continue operations merrily.
HURD_LOGMSG FUNCTION:
The libc library will provide a function 'hurd_logmsg' and wrapper
macros called 'hurd_debug', 'hurd_warning', and 'hurd_error' for easy
use. The hurd_logmsg function will perform a path lookup on
'/servers/hurdlog' to obtain the first argument to the RPC and all
other arguments will be obtained by the caller. The function will
be implemented using 'stdarg' so that 'printf' style semantics can
be used in calling the function.
For easy use, macros will provide the 'filename' and 'lineno'
parameters using the __FILE__ and __LINE__ standard C macros.
The definition of the macros is something closely resembling
the following:
#ifdef HAVE_HURDLOG_WARNING
#define hurd_warning(fmt...) \
hurd_logmsg(__FILE__, __LINE__, HURDLOG_DEBUG, fmt)
#else
#define hurd_warning(fmt...)
#endif
Note that the definition of these macros allows one to call them
without fear of code bloat since each macro can be compiled in and
out easily, allowing one to adjust the extent of logging used in
a given instance of the Hurd.
HURD LOGGING FACILITY USAGE GUIDELINES:
Because the macros can be easily compiled in and out, the use of the
hurd logging facility is highly encouraged at all points throughout
the hurd translator code. The more logging is available, the more
options one has to activate the logging and view messages, keeping
track of hurd behavior over an extended period of time. The
availability
of the logging facility also provides programmers an alternative to the
somewhat harsh 'assert()' macro for keeping track of 'interesting'
conditions.
The following code fragment (taken from auth.c) illustrates a potential
use
of the hurd logging facility:
if (rendezvous == MACH_PORT_DEAD) {/* Port died in transit. */
hurd_warning("Mach port died in transit");
return EINVAL;
}
In this way, the user presented with 'EINVAL' has no way of divining
that there is a problem with the rendevous port and reporting the
error in a meaningful way. Instead of reporting 'I did an ls' and
got 'Invalid Argument' the user may report the error and line number
of the failed event (if logging is enabled).
KNOWN PROBLEMS/BUGS:
Because the 'hurdlog' translator uses 'open' and 'write', care must
be taken to avoid recursive calls. A solution to this problem is not
redily aparent to the author and suggestions are welcome.
The possibility exists for users to flood the log port. A solution to
this problem does not redily exist although since the translator does
not have to be enabled for the system to run, users concerned about
security are free to disable the translator altogether without determent
to the usability of the system. They will merely not see log messages
at all.
--
------------------------------------------------------------------------
Jonathan S. Arney
Software Engineer
[EMAIL PROTECTED]
------------------------------------------------------------------------
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
