Re: [MirageOS-devel] Logs

[Thomas Leonard <talex5@xxxxxxxxx>]

On 24 October 2015 at 15:55, 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).

stdout/stderr is something OCaml programs can generally assume exists.
If someone makes a new OCaml platform, it's up to them to make sure
they do something sensible (mirage-xen sends output to the default
console, for example). Otherwise, we'd have to ban people from using
print_endline by default too (which might make sense for a new
language, but it's too late now for OCaml).

If we choose [3], then any library author adding a warning or error to
their code will cause some of their users' programs to crash. This
will discourage people from adding logging to their code.

As I recall, java.util.logging did [1] and it was very annoying. Even
if the application author goes to the trouble of configuring logging,
they won't necessarily configure *this* logging library. In Java land,
you might configure log4j but still not see a warning because it was
reported using java.util.logging instead.

If library authors know their warnings and errors will be ignored by
default then again they're likely to ignore the logging system and
write to stderr directly.

Finally, if you really want to crash if things aren't configured, you
should at least do it immediately at start-up so the problem can be
detected at deployment time, not wait until a serious problem occurs
in production and then crash instead with an error about the logging
configuration.


tl;dr: I also prefer [2]


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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