Re: [MirageOS-devel] Logs

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le vendredi, 16 octobre 2015 Ã 11:11, Anil Madhavapeddy a Ãcrit :
> I really like this library except for the notion of log levels. [â] with the 
> level stuff added by a higher level logger/monitor?

I don't see how a higher-level structure could decide if that string message is 
informational, a warning or an error afterwards (which are error classes that 
happen quite naturally in my opinion). In any case in the proposed library 
there are two ways to control if a log entry is reported

1) Levels
2) Sources

You are of course free to define only a source and use a single level of your 
choice (e.g. Show which should maybe renamed). But I think I will try to 
abstract the notion of level under a larger notion of tag, see below. Entries 
should carry a set of tags. The Log.{warn,err} etc would then just add 
predefined tags for these classes. Maybe sources could actually also be tags. 
I'll try to think something along these lines.

> And debugk in that pull request answers my query nicely:
>  
> Log.debugk "received %s (%s)" @@ fun k -> k (pretty k) (pretty v)
I prefer my version mentioned on the same page

  Log.debug "received %a (%a)" pp_key k pp_value v

which is the natural way of using Format. Jeremy may want to comment on the 
performance results though.


Le vendredi, 16 octobre 2015 Ã 11:23, Hannes Mehnert a Ãcrit :
> Certainly this could be a layer on top of the simple logging library,
> but it might be handy to have it embedded at the lowest level. What do
> others think?

Maybe. As said above I'll try to see if I can find a convenient way to 
generalize the notion of level into a notion of "tag". Reporters can then 
simply consult the tags of an entry to perform what they like. As far as tag 
UUID generation is concerned I don't think that anything automated would be 
practical as you need to be able to control the UUID over more than one version 
of the software (which rules out source code position based hacks).

Best,

Daniel
  





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