Re: [MirageOS-devel] Thoughts on logging

[Thomas Leonard <talex5@xxxxxxxxx>]

On 3 December 2015 at 00:12, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le mercredi, 2 dÃcembre 2015 Ã 17:24, Thomas Leonard a Ãcrit :
>> Logging came up in today's call again, and it was suggested that
>> perhaps we could get started by adding a LOG signature to
>> mirage-types.
>
> I think that this would be a design error. I'd rather say that in general one 
> should rather think about removing things from mirage-types. Each package 
> that manages to provide a useful service for mirage without having to depend 
> on mirage-types or that depends on it only optionally should be considered a 
> greater success than one that depends on it. I think that ocaml-tls' design 
> has shown a way here.
>
> The question to ask is what does mirage-types represents, what does one put 
> there ? My own take on this would be that mirages-types should only contain 
> signatures that are necessary for interacting with the underlying 
> drivers/hardware/hypervisor interface. By this rule we can quickly see that 
> putting logging there is very suspicious â of course log *reporting* may 
> actually interact with the hardware but the whole point of a good logging 
> system is to be able to decouple logging from reporting.

Yes, it would be good to clarify this. My view is that mirage-types
should be for "module types that have been specified/standardised by
the Mirage project". i.e. projects that use these types are more
likely to work together. So mirage-types is the Mirage equivalent of
POSIX.

With that said, once Logs is released we might migrate things to use
that directly.

>> - I'm not sure about the callback-based syntax. e.g.
> I also found it a bit surprising in the beginning but I got used to it. 
> Besides I quite like the clear and scoped delineation it makes between what 
> you compute only for logging and your program. As for using syntax extensions 
> I will not comment on this since I have been asked to watch my language.

Yes, OK, I think I'll go with that API.

>> David Sheets mentioned the example of testing a protocol with two
>> endpoints, each with their own logger, for example. It also allows
>> libraries to avoid depending on any particular library, if they prefer
>> not to do that. And, it prevents libraries from using their loggers
>> before the logging system is configured.
>
> Note that both the first thing and last thing you mention can be solved in 
> Logs using sources, which can be attached e.g. to connections/contexts or 
> specified in the library initialization function if there is one. Or, if you 
> absolutely need to use the functor hammer, you can simply specify a source in 
> a functor argument, but there's no need to functorize over the whole logging 
> interface â or at least I wouldn't do that.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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