Re: [MirageOS-devel] Logging (was: test, quality, tcpip)

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 12 May 2015, at 10:27, Matthew Gray <matthew.thomas.gray@xxxxxxxxx> wrote:
> 
> On Wed, May 6, 2015 at 1:58 PM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> 
> wrote:
> 
> An other point which is cruelly missing is a proper logging system - which is 
> central when debugging runtime errors.
> 
> Thomas, do you have any thoughts about what a proper logging system would 
> look like? What features it would provide? I'm experimenting a little with 
> this already, making a logger that can write messages to the console and also 
> send as syslog. I'd be interested in trying to expand this and make it into 
> something generally useful for Mirage but would probably need a bit of 
> guidance to begin with. 
> 
> I'm aware of https://github.com/UnixJunkie/dolog and wondering whether this 
> is a good starting point, if it were functorized to accept the Mirage console 
> signature?

Now that the TLS stack is spooled up for integration (and running live on 
https://mirage.io!), this is actually top of my list.  There are a few 
properties I want from a logging library:

- An extremely small core interface, with just the "log" function (and 
associated format string ones).  This lets us have a trivial, dependency free 
implementation that just logs to stdout or the Xen console.

- Ability to branch logging contexts, to have hierarchical logs.  This lets us 
map to both Irmin and the JavaScript logging interface very effectively.  See 
[1] for the Firebug console.group() function.

- Build more complex backends over this basis.  For instance, the conventional 
"info/error/debug" one would be a layer that does the branches appropriately 
for each type.  Another guideline is Thomas Leonard's profiling library, which 
should hook into this logging layer.  Finally, the Xen backend should use Irmin 
to provide a Git logging backend, where log branches are actual Git branches.

- Ban all uses of console logging from all of our protocol libraries.  We 
should *never* be logging directly to the console, as this is both a 
denial-of-service opportunity and something that is very difficult to aggregate 
and track.

My thinking is that by keeping the core interface down to one function, it 
should be possible for the application to be passed a logging function very 
easily (~log), and for the build system to assemble the appropriate logging 
backend for the environment at hand.  We could then add a ~log function to 
Cohttp, DNS, TCPIP etc, with a PPX/Camlp4 extension to make it a lazy function 
for when we don't want it to be evaluated all the time.

What I don't want is something like Dolog, which is a fine logging library, but 
a bit too specific to be used pervasively throughout our protocol libraries 
that must remain portable and lightweight across multiple compilation 
environments.

Thoughts on this most welcome... I feel that building this library is quite 
simple, but getting the design right is critical as it will be a dependency on 
every library that we have.

[1] https://getfirebug.com/wiki/index.php/Console_API

-anil


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