Re: Question about TRACEPOINT_FORMAT

Re: Question about TRACEPOINT_FORMAT

[Amit Margalit]

[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]

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@IBMIL
To:     lttng-dev@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. 

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@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


[-- Attachment #1.2: Type: text/html, Size: 3853 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

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

Re: Question about TRACEPOINT_FORMAT

[Mathieu Desnoyers]

* Amit Margalit (AMITM@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@IBMIL
> To:     lttng-dev@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@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

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


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

Re: Question about TRACEPOINT_FORMAT

[Amit Margalit]

[-- Attachment #1.1: Type: text/plain, Size: 2890 bytes --]

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@efficios.com>
To:     Amit Margalit/Israel/IBM@IBMIL
Cc:     lttng-dev@lists.lttng.org
Date:   07/04/2013 04:06 PM
Subject:        Re: [lttng-dev] Question about TRACEPOINT_FORMAT



* Amit Margalit (AMITM@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@IBMIL
> To:     lttng-dev@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@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

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


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



[-- Attachment #1.2: Type: text/html, Size: 4903 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

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

Question about TRACEPOINT_FORMAT

[Amit Margalit]

[-- Attachment #1.1: Type: text/plain, Size: 1246 bytes --]

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.

Thanks,

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

[-- Attachment #1.2: Type: text/html, Size: 1947 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

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