[lttng-dev] Question about TRACEPOINT_FORMAT

[Amit Margalit]

To me, your suggestion seems simple and elegant, but my experience in this 
area is still rather small...

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230



From:   Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
To:     Amit Margalit/Israel/IBM at IBMIL
Cc:     lttng-dev at lists.lttng.org
Date:   07/04/2013 04:06 PM
Subject:        Re: [lttng-dev] Question about TRACEPOINT_FORMAT



* Amit Margalit (AMITM at il.ibm.com) wrote:
> Hi,
> 
> I never got any response to this. Anyone care to comment?
> 
> Thanks,
> 
> Amit Margalit
> IBM XIV - Storage Reinvented
> XIV-NAS Development Team
> Tel. 03-689-7774
> Fax. 03-689-7230
> 
> 
> 
> From:   Amit Margalit/Israel/IBM at IBMIL
> To:     lttng-dev at lists.lttng.org
> Date:   06/04/2013 10:41 AM
> Subject:        [lttng-dev] Question about TRACEPOINT_FORMAT
> 
> 
> 
> Hello, 
> 
> I've read the discussion in the past about this suggested feature, and 
I'd 
> like to ask what has become of this. Is this still being considered? Has 

> anyone come up with an idea for a solution that does not include 
extending 
> CTF? 
> 
> I understand that CTF doesn't support looking into the ELF binary, but 
> perhaps there is a way around this. 
> 
> First, I'd like to explain what I wish to have, so that maybe a 
different 
> solution could be suggested - 
> In all, migration from an existing log-to-file system for existing 
> projects may push the entire formatted string as the trace entry. 
> We'd like to avoid storing the entire format string multiple times, as 
> this is wasteful, of course, and we'd like the viewer to be in charge of 

> performing the formatting. 
> 
> I was wondering whether we could use CTF enums. The CTF specification 
for 
> enums doesn't say that the textual representation of the value has to be 
a 
> valid identifier. In fact, the example includes a quoted string. 
> 
> An instrumentation tool could generate code that writes an enum 
> description into the metadata, where each value corresponds to a 
different 
> format string. 

I have something quite simpler in mind for this, but it involves
extending the CTF spec. Adding, to the event {} description within the
metadata, something like:

event {
        ...
        format = "This is the first field: %u and the second: %llu";
        ...
}

Thoughts ?

Thanks,

Mathieu

> 
> Thanks, 
> 
> Amit Margalit 
> IBM XIV - Storage Reinvented 
> XIV-NAS Development Team 
> Tel. 03-689-7774 
> Fax. 03-689-7230_______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130705/999ed22e/attachment.html>