Re: [MirageOS-devel] Logs

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

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).

Best,  

Daniel

   



_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel