Re: [MirageOS-devel] Tracing and profiling blog post

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 30 Oct 2014, at 09:36, Thomas Leonard <talex5@xxxxxxxxx> wrote:

> Here's what I have so far:
> 
> https://github.com/talex5/mirage-profile/blob/new-api/lib/trace_stubs.mli
> https://github.com/talex5/mirage-profile/blob/new-api/lib/counter.mli
> 
> There's not much here, but it would be good to keep this API stable as
> pretty much all mirage libraries will be using it.

some quick thoughts:

trace_stubs.mli:

would it make sense for note_{suspend,resume} to be string -> unit (or some 
more opaque type than string even, though perhaps of fixed size) so that the 
programmer can indicate reasons for the suspend/resume?

can labels on threads be changed over their lifetime?  can labels overlap or 
are they unique?  if unique, within what context?

trace_enabled.mli:

how do i interact with the buffer other than to snapshot it?

...and what's counter for?  (ie., how general/widely used is it intended to be?)

> The API for controlling the tracing, dumping out events, etc is much
> less critical and can be changed later, as it only matters to the
> developer profiling their unikernel.

agree to some extent -- though if some components wish to control tracing in 
other components as a result of observation of their own behaviour, the control 
API may become  more pervasively used than the dumping/display api i guess.

-- 
Cheers,

R.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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