[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Logs

Very sorry, I meant to send that to the list as well.

-Spiros E.

On Sat, Oct 24, 2015 at 10:55 AM, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:

Spiros sent this. I respond on the list I hope he doesn't mind. My response is below his message.

Le samedi, 24 octobre 2015 Ã 14:45, Spiros Eliopoulos a Ãcrit :

> > 1) nop reporter (do absolutely nothing)
> > 2) stderr reporter (vomits on stderr)
> > 3) invalid reporter (throws in your face)
> It should be #2. Ideally, adding logging to a program would not change its behavior at all. Obviously not the case in practice but that's the goal. Adding a logging dependency and (for example) logging the fact that a program started should still run the program. Adding a library dependency that includes unconfigured loggging calls should also still run the program. Throwing an exception is about as big of a deviation from normal program behavior that you can get. It should not be #3.
> While unmodified program behavior is the goal, that's of course not feasible in practice for the very reason that logging modifies the program. It adds new lines of code which adds new computation, be it just NOOP function calls. More importantly though, the addition of logging calls is an attempt to collect diagnostic and progress information by the programmer, and report it to the user. Their very presence suggests that they're important, so the information they collect should not be discarded unless there is an explicit request to do so. It should not be #1.
> Stderr was quite literally invented for reporting errors and diagnostic information without cluttering stdout[0]. It should be #2.
> -Spiros E.
> [0]: http://www.spinellis.gr/blog/20131211/

I disagree that "ideally adding logging to a program would not change its behaviour at all". I think you are mixing program instrumentation and logging. Logging by summarizing computation is a creative act and has an effect on the program output that cannot be ignored; in an interactive program it may even trigger a feedback command from the user to the program so for me logging *has* to part of the program behaviour. Which invalidates for me your argument that it should not be 3).

My concern with 2) is that's it is equivalent to either 1) or 3) when the concept doesn't exist (e.g. on bare metal) and I prefer consistent and visible behaviour regardless of context; this is why I lean towards 3).



MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.