Re: [MirageOS-devel] Mirage tracing

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 9 Oct 2014, at 12:48, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

>>> I think we were discussing having a special "Tracer" (or "Profiler") module 
>>> type, similar to the "Console" one. Or to extend the "Console" one with 
>>> more structured kinds of debug statement. Not sure what is the most 
>>> practical, but we should certainly do something to support what you have 
>>> started to do at a larger scale.
>>> 
>>> And yes, having a dummy Profiler where no-op are optimised away is a good 
>>> idea. Hopefully, Pierre Chambart's patches for improving the inliner will 
>>> be in OCaml before Mirage 3.0 :-)
>> 
>> Yes -- this is one area where the camlp4/ppt pa_lwt syntax extension comes 
>> in quite useful.   We could have a different switch for profile-enabled or 
>> disabled libraries, and perform the additional logging registration there.  
>> See the logging support that pa_lwt already has...
> 
> maybe it's a good time to resurrect the extreme tracing pa_trace stuff as 
> well: https://searchcode.com/codesearch/view/25096556/

The resurrection may be simplified by:

https://github.com/avsm/ocaml-fbt-trace

This is a very simple extraction that introduces a function boundary logger
via camlp4, and the application links against a logging library that does
something with the result.  There's an example in lib_test of how it works.

More broadly, this is precisely why the ongoing Assemblage project description
library by Thomas and Daniel is so important.  It would be great to have the
ability to quickly swap in a profiling variant of a particular module or
library, and it's currently very hard to do this without finer control over
the build systems.

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