Re: [MirageOS-devel] Logging

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 12 May 2015, at 16:48, Drup <drupyog+caml@xxxxxxxx> wrote:
> 
>> Agreed. I had in mind a branching structure that would include a branch per 
>> component, followed by the debug levels.  Other listeners could then do 
>> aggregation into different views, including operations such as time-based 
>> rotation and aggregation across components.  For an Irmin backend, such 
>> listeners can just be watchers (either offline or online, which is nice!).
> If I understand correctly, this would allow to encode Lwt_log's sections 
> quite easily, is that right ? It is a feature that I found rather lacking in 
> other logging libraries (in particular, dolog).

That's right; it should allow Lwt_log's sections (but not the levels).

> I like your "only one function" idea.
> The alternative of passing around the unique function is to have a global 
> reference containing the dispatcher function. It's the solution used by 
> Lwt_log. It's mostly equivalent (and it works ok in practice) but I think 
> it's indeed better to pass the function explicitly.

It should be possible to stash the logging function somewhere more convenient 
than every single function, but this depends on the library.  In Cohttp and 
Conduit, the `ctx` context is a good place.  For DNS, it's probably enough to 
pass it in to the library functions since they are fairly stateless.

> I'm not really convinced by the extension syntax trick (it was done for 
> Lwt_log too and it uses a very syntactic criteria, which makes it a bit 
> fishy). What would it do exactly ? Can't you rely on partial evaluation and 
> Flambda's inlining to do the correct thing ?

Sure.  I don't really mind how the lazy log is implemented.  Expensive logging 
can just be hidden behind an explicit if/else, since we really do want logging 
to be turned on by default in production deployments (and so it should be cheap 
enough by default, and factored into performance benchmarks).

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