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 <[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
--
Adam Olsen, aka Rhamphoryncus
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
