Re: Hurd logging. (was zalloc panic)

[Adam Olsen]

On Thu, Feb 28, 2002 at 10:15:12PM -0700, Jon Arney wrote:
> 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.

I think we should create a mechanism for the stdout and stderr of
passive translators to be logged, perhaps using /servers/log or
something else.  Then build on that by adding a syslog-ish rpc, and
modifying the syslog function so that it uses the rpc if stdout
supports it, or falling back to a pretty-printed form if it doesn't.

Hmm, or maybe we should always use a human-readable form rather than
an rpc.  just make them use a syntax of [ident] <priority> message
(with all the special characters (including newline) being escaped),
or something of the sort.

> 
> ------------------------------------------------------
> 
> Proposal for a HURD logging facility
> Jonathan S. Arney <jarney1@cox.net>
> 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
> jarney1@cox.net
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Bug-hurd mailing list
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd

-- 
Adam Olsen, aka Rhamphoryncus