Re: [MirageOS-devel] Logging

[Rudi Grinberg <rudi.grinberg@xxxxxxxxx>]

> 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 curious about this comment about cohttp. There was actually a request on the bug tracker asking for better logging in cohttp but I mostly turned it down because it seems like any kind of logging you might want cohttp to do can be easily accomplished outside of cohttp. For example, if youâre using a cohttp as an http client, you only need to wrap your call function to print the request before itâs sent and the response just after it arrives. Adding this kind of logging to a cohttp server is similar.

In fact, for the client use case we could really make it trivial for a user to add his own logging if we exposed a function that would construct all the little helpers such as get/post/put/delete/etc. from a basic log aware call function.

Of course, this approach is inadequate if you want to log something that pertains cohttpâs internals. Which is exactly why we have the COHTTP_DEBUG env var today. I was never a huge fan of his approach either and have thought about improving it by introducing a functor (if you can call that an improvement) IO -> IO that would take a normal IO backend and return a logging one (or at least a COHTTP_DEBUG accepting one). But Iâm not yet sure if this an improvement.

Anyhow, this is getting off topic. I just mean to bring some for less intrusive approaches for logging.

> 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 

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