Re: [MirageOS-devel] test, quality, tcpip

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

Le mardi, 12 mai 2015 Ã 23:54, Thomas Gazagnaire a Ãcrit :
> - I'm not a big fan of passing the logging function as an argument as this 
> means you need to thread it everywhere (and if you want to add some logging 
> to a function, you'll need to change its type)
I have tried the passing the logging function thing and it is both ugly and 
annoying.


> so the design of Lwt_log is compelling - but need to thing a bit more about 
> that
Having a quick look at Lwt_log's section support I'm not very fond of their 
idea of having sections being name (string) based, this is anti-modular (in the 
sense of visibility control): any component can access any section.  

I rather think that section values themselves should be used as log witnesses, 
this allows components to declare in the module system on which section they 
log. This declaration provides a handle for component users to configure the 
component's logging. These witnesses could come in both private and public 
forms. Public logs allow other components to also log on them (via the 
witness), while private do not (can only be used to configure the logging). 
Mirage (or the log module) could then provide a few standard high-level public 
logs on which components advertise their essential information while they use 
their own private logs for more detailed information.

> - I quite like the "with-trace" function of bigloo[1] and I found it quite 
> useful in practice (although I would replace the trace level by some section 
> names that you could turn-off/on dynamically and/or statically)
This looks like OCaml toplevel #trace directive, I never managed to debug 
anything with that. When you #trace you are looking at a black box operating 
and it usually not very usefulâ (at least for debugging).

> - It is always hard to find the right balance of things to log or to not log 
> and I'm not sure how we can have a general solution for this without runtime 
> control. Spamming the log traces is very useful when you debug and or when 
> you try to fix a weird production issue, but you also want to be fast and 
> avoid DoS ...
It seems there's a good distinction *to be found* between tracing and logging. 
Tentatively tracing is really about debugging, logging can also be but I tend 
to look it more as an affordance to assess the high-level history and current 
state of the system. For example if your unikernel doesn't get an IP address 
maybe there's a problem with your network but not with the unikernel itself and 
you want to be able to quickly asses that in the logs, highly detailed tracing 
wouldn't be necessary here.  
  
> - If anyone knows a good existing logging library that they used in other 
> languages, I'm keen to have a look.

I know one *not to look at*, Log4j (at least v1) a good example of oo 
bureaucratic non-sense.  

Daniel



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