Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Jan Glauber]

On Mon, May 13, 2013 at 10:16:04AM +0400, Anna Dushistova wrote:
> Hi Jan,
> 
> I tried out your patch for the 2.6->ctf converter(
> http://lists.lttng.org/pipermail/lttng-dev/2013-April/020081.html)
> with the following trace:
> https://github.com/fchouinard/LTTng/blob/master/samples/trace-2.6-22K.tar.gz
> 
> from
> http://wiki.eclipse.org/Linux_Tools_Project/LTTng/User_Guide#Downloading_Sample_Tracesand
> it crashed
> with segmentation fault.

Hi Anna,

could it be that the tar file itself is in the trace directory when you run babeltrace-legacy?
I think I've only implemented rudimentary file checking, so the legacy converter assumes
all files in the directory belong to the trace. Please try removing any files that do not belong
to the trace.

That said, the converter should better check all files for the correct header...

Regards, Jan
 
> Anna.

-- 
Jan Glauber
---
Harman Becker Automotive GmbH
System Profiling & Optimizing Team

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Anna Dushistova]

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

Hi Jan,

I tried out your patch for the 2.6->ctf converter(
http://lists.lttng.org/pipermail/lttng-dev/2013-April/020081.html)
with the following trace:
https://github.com/fchouinard/LTTng/blob/master/samples/trace-2.6-22K.tar.gz

from
http://wiki.eclipse.org/Linux_Tools_Project/LTTng/User_Guide#Downloading_Sample_Tracesand
it crashed
with segmentation fault.

Anna.

[-- Attachment #1.2: Type: text/html, Size: 786 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: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Matthew Khouzam]

No problems here. I was inquiring about this so that nobody is surprised
if all trace viewers features are not supported.
On 13-04-23 08:14 AM, Jan Glauber wrote:
> On Mon, Apr 22, 2013 at 11:55:59AM -0400, Yannick Brosseau wrote:
>> On 2013-04-22 11:51, Matthew Khouzam wrote:
>>> On 13-04-22 08:55 AM, Jan Glauber wrote:
>>>> On Fri, Apr 19, 2013 at 11:03:39AM -0400, Matthew Khouzam wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I have a few questions about the patch:
>>>>> Does it handle lost events?
>>>>> I think we would need to bring in a state system for this
>>>> Hi Matthew,
>>>>
>>>> Not sure what you mean there. I thought lost events are not recorded so there is
>>>> nothing to convert. What I do convert is the events_lost counter of LTT. The
>>>> value is copied to the events_discarded of LTTng. At least that looked reasonable
>>>> to me. Can you elaborate why we would need a state machine there?
>>> In lttv, the control flow view and company needs a state system. The
>>> events in lttng 0.x and 2.0 are slightly different, so we won't see
>>> stuff like the current TID and file statuses. I'm just giving you the
>>> heads up that it may be not so trivial to get the info. The best thing
>>> to do IMO is look up events in LTTng 2.0 and try to match the ones you
>>> have in babeltrace to them.
>>> That way, it will work with lttv and eclipse.
>>>
>> I'm not sure either that I understand what you mean.
>>
>> The goal is just to convert traces, not create a whole state system.
>> When we will be able to get a converted trace, the viewers could adjust
>> to support them.
> Yannick is right, these patches are just for converting the raw trace data.
> Interpreting the converted trace data is then up to LTTV or Eclipse.
>
> Conversion of the trace data to the concrete CTF description LTTng 2.x is
> using would be quite hard and require also to convert the trace data itself
> (which I avoided so far...).
>
> -- Jan
>
>  
>> Yannick

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Jan Glauber]

On Mon, Apr 22, 2013 at 11:55:59AM -0400, Yannick Brosseau wrote:
> On 2013-04-22 11:51, Matthew Khouzam wrote:
> > On 13-04-22 08:55 AM, Jan Glauber wrote:
> >> On Fri, Apr 19, 2013 at 11:03:39AM -0400, Matthew Khouzam wrote:
> >>> Hi Jan,
> >>>
> >>> I have a few questions about the patch:
> >>> Does it handle lost events?
> >>> I think we would need to bring in a state system for this
> >> Hi Matthew,
> >>
> >> Not sure what you mean there. I thought lost events are not recorded so there is
> >> nothing to convert. What I do convert is the events_lost counter of LTT. The
> >> value is copied to the events_discarded of LTTng. At least that looked reasonable
> >> to me. Can you elaborate why we would need a state machine there?
> > In lttv, the control flow view and company needs a state system. The
> > events in lttng 0.x and 2.0 are slightly different, so we won't see
> > stuff like the current TID and file statuses. I'm just giving you the
> > heads up that it may be not so trivial to get the info. The best thing
> > to do IMO is look up events in LTTng 2.0 and try to match the ones you
> > have in babeltrace to them.
> > That way, it will work with lttv and eclipse.
> >
> I'm not sure either that I understand what you mean.
> 
> The goal is just to convert traces, not create a whole state system.
> When we will be able to get a converted trace, the viewers could adjust
> to support them.

Yannick is right, these patches are just for converting the raw trace data.
Interpreting the converted trace data is then up to LTTV or Eclipse.

Conversion of the trace data to the concrete CTF description LTTng 2.x is
using would be quite hard and require also to convert the trace data itself
(which I avoided so far...).

-- Jan

 
> Yannick

-- 
Jan Glauber
---
Harman Becker Automotive GmbH
System Profiling & Optimizing Team

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Yannick Brosseau]

On 2013-04-22 11:51, Matthew Khouzam wrote:
> On 13-04-22 08:55 AM, Jan Glauber wrote:
>> On Fri, Apr 19, 2013 at 11:03:39AM -0400, Matthew Khouzam wrote:
>>> Hi Jan,
>>>
>>> I have a few questions about the patch:
>>> Does it handle lost events?
>>> I think we would need to bring in a state system for this
>> Hi Matthew,
>>
>> Not sure what you mean there. I thought lost events are not recorded so there is
>> nothing to convert. What I do convert is the events_lost counter of LTT. The
>> value is copied to the events_discarded of LTTng. At least that looked reasonable
>> to me. Can you elaborate why we would need a state machine there?
> In lttv, the control flow view and company needs a state system. The
> events in lttng 0.x and 2.0 are slightly different, so we won't see
> stuff like the current TID and file statuses. I'm just giving you the
> heads up that it may be not so trivial to get the info. The best thing
> to do IMO is look up events in LTTng 2.0 and try to match the ones you
> have in babeltrace to them.
> That way, it will work with lttv and eclipse.
>
I'm not sure either that I understand what you mean.

The goal is just to convert traces, not create a whole state system.
When we will be able to get a converted trace, the viewers could adjust
to support them.

Yannick

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Matthew Khouzam]

On 13-04-22 08:55 AM, Jan Glauber wrote:
> On Fri, Apr 19, 2013 at 11:03:39AM -0400, Matthew Khouzam wrote:
>> Hi Jan,
>>
>> I have a few questions about the patch:
>> Does it handle lost events?
>> I think we would need to bring in a state system for this
> Hi Matthew,
>
> Not sure what you mean there. I thought lost events are not recorded so there is
> nothing to convert. What I do convert is the events_lost counter of LTT. The
> value is copied to the events_discarded of LTTng. At least that looked reasonable
> to me. Can you elaborate why we would need a state machine there?

In lttv, the control flow view and company needs a state system. The
events in lttng 0.x and 2.0 are slightly different, so we won't see
stuff like the current TID and file statuses. I'm just giving you the
heads up that it may be not so trivial to get the info. The best thing
to do IMO is look up events in LTTng 2.0 and try to match the ones you
have in babeltrace to them.
That way, it will work with lttv and eclipse.

I honestly feel I am being unclear, don't hesitate to ask for more
precisions.
>
>> Is there a reason lttng2.0 is not working for you? kernel? install base?
>> other?
> The reason is that we have multiple install bases and some are on LTT with no
> option of upgrading them to LTTng.
>
>> Do you want just a list of the events or analysis on the trace later on.
> We would like to analyse traces from different sources with Eclipse and
> especially using the CTF classes.
>
>> Can you post an example of a converted trace?
> Sure, here's a short snapshot of the converted trace viewed with babeltrace,
> somewhere in the middle of a not too spectacular trace but at least with events
> from some different components:
>
> [10:42:48.534746510] (+0.000001741) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 716048728, syscall_id = 263 }
> [10:42:48.534748034] (+0.000001524) none fs_pollfd: { cpu_id = 0 }, { fd = 27 }
> [10:42:48.534748132] (+0.000000098) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 0 }
> [10:42:48.534751362] (+0.000003230) none fs_pollfd: { cpu_id = 0 }, { fd = 28 }
> [10:42:48.534754469] (+0.000003107) none fs_pollfd: { cpu_id = 0 }, { fd = 29 }
> [10:42:48.534757482] (+0.000003013) none fs_pollfd: { cpu_id = 0 }, { fd = 20 }
> [10:42:48.534761354] (+0.000003872) none fs_pollfd: { cpu_id = 0 }, { fd = 22 }
> [10:42:48.534764045] (+0.000002691) none fs_pollfd: { cpu_id = 0 }, { fd = 30 }
> [10:42:48.534767272] (+0.000003227) none fs_pollfd: { cpu_id = 0 }, { fd = 31 }
> [10:42:48.534770512] (+0.000003240) none fs_pollfd: { cpu_id = 0 }, { fd = 32 }
> [10:42:48.534774102] (+0.000003590) none fs_pollfd: { cpu_id = 0 }, { fd = 33 }
> [10:42:48.534777510] (+0.000003408) none fs_pollfd: { cpu_id = 0 }, { fd = 35 }
> [10:42:48.534781767] (+0.000004257) none fs_pollfd: { cpu_id = 0 }, { fd = 36 }
> [10:42:48.534785282] (+0.000003515) none fs_pollfd: { cpu_id = 0 }, { fd = 37 }
> [10:42:48.534788669] (+0.000003387) none fs_pollfd: { cpu_id = 0 }, { fd = 34 }
> [10:42:48.534791977] (+0.000003308) none fs_pollfd: { cpu_id = 0 }, { fd = 38 }
> [10:42:48.534795069] (+0.000003092) none fs_pollfd: { cpu_id = 0 }, { fd = 39 }
> [10:42:48.534798194] (+0.000003125) none fs_pollfd: { cpu_id = 0 }, { fd = 40 }
> [10:42:48.534801197] (+0.000003003) none fs_pollfd: { cpu_id = 0 }, { fd = 41 }
> [10:42:48.534804389] (+0.000003192) none fs_pollfd: { cpu_id = 0 }, { fd = 42 }
> [10:42:48.534807827] (+0.000003438) none fs_pollfd: { cpu_id = 0 }, { fd = 43 }
> [10:42:48.534811137] (+0.000003310) none fs_pollfd: { cpu_id = 0 }, { fd = 44 }
> [10:42:48.534814215] (+0.000003078) none fs_pollfd: { cpu_id = 0 }, { fd = 45 }
> [10:42:48.534817354] (+0.000003139) none fs_pollfd: { cpu_id = 0 }, { fd = 46 }
> [10:42:48.534820489] (+0.000003135) none fs_pollfd: { cpu_id = 0 }, { fd = 47 }
> [10:42:48.534823479] (+0.000002990) none fs_pollfd: { cpu_id = 0 }, { fd = 48 }
> [10:42:48.534826875] (+0.000003396) none fs_pollfd: { cpu_id = 0 }, { fd = 49 }
> [10:42:48.534830315] (+0.000003440) none fs_pollfd: { cpu_id = 0 }, { fd = 50 }
> [10:42:48.534834449] (+0.000004134) none fs_pollfd: { cpu_id = 0 }, { fd = 51 }
> [10:42:48.534837717] (+0.000003268) none fs_pollfd: { cpu_id = 0 }, { fd = 52 }
> [10:42:48.534841064] (+0.000003347) none fs_pollfd: { cpu_id = 0 }, { fd = 53 }
> [10:42:48.534844754] (+0.000003690) none fs_pollfd: { cpu_id = 0 }, { fd = 54 }
> [10:42:48.534849177] (+0.000004423) none fs_pollfd: { cpu_id = 0 }, { fd = 55 }
> [10:42:48.534892997] (+0.000043820) none mm_page_free: { cpu_id = 0 }, { pfn = 158205, order = 0 }
> [10:42:48.534993555] (+0.000100558) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 716868028, syscall_id = 296 }
> [10:42:48.535000284] (+0.000006729) none net_socket_recvmsg: { cpu_id = 0 }, { sock = 0xB5F324E0, msg = 0x983FFF74, size = 2048, flags = 1073741888, ret = 660 }
> [10:42:48.535011094] (+0.000010810) none net_socket_sendmsg: { cpu_id = 1 }, { sock = 0xB5CE8B20, msg = 0xB6031F74, size = 463, ret = 463 }
> [10:42:48.535013404] (+0.000002310) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 463 }
> [10:42:48.535202519] (+0.000189115) none net_socket_recvmsg: { cpu_id = 0 }, { sock = 0xB5F324E0, msg = 0x983FFF74, size = 2048, flags = 1073741888, ret = -11 }
> [10:42:48.535231537] (+0.000029018) none kernel_sched_try_wakeup: { cpu_id = 1 }, { pid = 68, cpu_id = 1, state = 256 }
> [10:42:48.535243069] (+0.000011532) none kernel_sched_schedule: { cpu_id = 1 }, { prev_pid = 1, next_pid = 68, prev_state = 0 }
> [10:42:48.535258092] (+0.000015023) none fs_pollfd: { cpu_id = 1 }, { fd = 5 }
> [10:42:48.535264639] (+0.000006547) none fs_pollfd: { cpu_id = 1 }, { fd = 9 }
> [10:42:48.535269929] (+0.000005290) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 1 }
> [10:42:48.535278789] (+0.000008860) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 717849364, syscall_id = 3 }
> [10:42:48.535299225] (+0.000020436) none fs_read: { cpu_id = 1 }, { count = 1, fd = 9 }
> [10:42:48.535300645] (+0.000001420) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 0 }
> [10:42:48.535306709] (+0.000006064) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 717837844, syscall_id = 240 }
> [10:42:48.535309234] (+0.000002525) none fs_ioctl: { cpu_id = 0 }, { fd = 4, cmd = 1075866368, arg = 745629032 }
> [10:42:48.535324412] (+0.000015178) none kernel_sched_migrate_task: { cpu_id = 1 }, { pid = 67, state = 256, dest_cpu = 0 }
> [10:42:48.535331534] (+0.000007122) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 1 }
> [10:42:48.535335210] (+0.000003676) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 718693652, syscall_id = 168 }
>
> Regards,
> Jan
>
>> Thanks
>> Matthew
>>
>>
>> On 13-04-19 06:20 AM, Jan Glauber wrote:
>>> Hi list,
>>>
>>> I've written a converter that can read LTT's 2.6 trace format and convert it
>>> to a CTF trace format. This was discussed before on the list:
>>>
>>> http://lists.lttng.org/pipermail/lttng-dev/2011-June/015995.html
>>>
>>> and I roughly followed the guidance given by Mathieu there. Roughly because
>>> I did not create plugins but followed the approach of babeltrace-log.
>>>
>>> How it works:
>>> - babeltrace legacy converter gets a directory containing a LTT 2.6 trace
>>>   and a target directory where it will create the converted trace
>>> - it scans the metadata_N files and creates a CTF which fits the old trace data
>>> - it scans all trace files and creates CTF headers but copies the trace data
>>> - empty files which contain only headers are not copied
>>>
>>> Is there any interest in picking up this code for babeltrace (or is it just
>>> too obscure :) ?
>>>
>>> Best regards,
>>>
>>> Jan Glauber
>>> Harman Becker Automotive GmbH
>>> System Profiling & Optimizing Team
>>>
>>> Jan Glauber (2):
>>>   Resurrect LTT type parser
>>>   babeltrace legacy LTT 2.6 -> CTF 1.8 converter
>>>
>>>  converter/babeltrace-legacy.c        | 1184 ++++++++++++++++++++++++++++++++++
>>>  converter/ltt-type-parser.c          |  303 +++++++++
>>>  include/babeltrace/ltt-type-parser.h |   17 +
>>>  3 files changed, 1504 insertions(+)
>>>  create mode 100644 converter/babeltrace-legacy.c
>>>  create mode 100644 converter/ltt-type-parser.c
>>>  create mode 100644 include/babeltrace/ltt-type-parser.h
>>>
>>
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Jan Glauber]

On Fri, Apr 19, 2013 at 11:03:39AM -0400, Matthew Khouzam wrote:
> Hi Jan,
> 
> I have a few questions about the patch:
> Does it handle lost events?
> I think we would need to bring in a state system for this

Hi Matthew,

Not sure what you mean there. I thought lost events are not recorded so there is
nothing to convert. What I do convert is the events_lost counter of LTT. The
value is copied to the events_discarded of LTTng. At least that looked reasonable
to me. Can you elaborate why we would need a state machine there?

> Is there a reason lttng2.0 is not working for you? kernel? install base?
> other?

The reason is that we have multiple install bases and some are on LTT with no
option of upgrading them to LTTng.

> Do you want just a list of the events or analysis on the trace later on.

We would like to analyse traces from different sources with Eclipse and
especially using the CTF classes.

> Can you post an example of a converted trace?

Sure, here's a short snapshot of the converted trace viewed with babeltrace,
somewhere in the middle of a not too spectacular trace but at least with events
from some different components:

[10:42:48.534746510] (+0.000001741) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 716048728, syscall_id = 263 }
[10:42:48.534748034] (+0.000001524) none fs_pollfd: { cpu_id = 0 }, { fd = 27 }
[10:42:48.534748132] (+0.000000098) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 0 }
[10:42:48.534751362] (+0.000003230) none fs_pollfd: { cpu_id = 0 }, { fd = 28 }
[10:42:48.534754469] (+0.000003107) none fs_pollfd: { cpu_id = 0 }, { fd = 29 }
[10:42:48.534757482] (+0.000003013) none fs_pollfd: { cpu_id = 0 }, { fd = 20 }
[10:42:48.534761354] (+0.000003872) none fs_pollfd: { cpu_id = 0 }, { fd = 22 }
[10:42:48.534764045] (+0.000002691) none fs_pollfd: { cpu_id = 0 }, { fd = 30 }
[10:42:48.534767272] (+0.000003227) none fs_pollfd: { cpu_id = 0 }, { fd = 31 }
[10:42:48.534770512] (+0.000003240) none fs_pollfd: { cpu_id = 0 }, { fd = 32 }
[10:42:48.534774102] (+0.000003590) none fs_pollfd: { cpu_id = 0 }, { fd = 33 }
[10:42:48.534777510] (+0.000003408) none fs_pollfd: { cpu_id = 0 }, { fd = 35 }
[10:42:48.534781767] (+0.000004257) none fs_pollfd: { cpu_id = 0 }, { fd = 36 }
[10:42:48.534785282] (+0.000003515) none fs_pollfd: { cpu_id = 0 }, { fd = 37 }
[10:42:48.534788669] (+0.000003387) none fs_pollfd: { cpu_id = 0 }, { fd = 34 }
[10:42:48.534791977] (+0.000003308) none fs_pollfd: { cpu_id = 0 }, { fd = 38 }
[10:42:48.534795069] (+0.000003092) none fs_pollfd: { cpu_id = 0 }, { fd = 39 }
[10:42:48.534798194] (+0.000003125) none fs_pollfd: { cpu_id = 0 }, { fd = 40 }
[10:42:48.534801197] (+0.000003003) none fs_pollfd: { cpu_id = 0 }, { fd = 41 }
[10:42:48.534804389] (+0.000003192) none fs_pollfd: { cpu_id = 0 }, { fd = 42 }
[10:42:48.534807827] (+0.000003438) none fs_pollfd: { cpu_id = 0 }, { fd = 43 }
[10:42:48.534811137] (+0.000003310) none fs_pollfd: { cpu_id = 0 }, { fd = 44 }
[10:42:48.534814215] (+0.000003078) none fs_pollfd: { cpu_id = 0 }, { fd = 45 }
[10:42:48.534817354] (+0.000003139) none fs_pollfd: { cpu_id = 0 }, { fd = 46 }
[10:42:48.534820489] (+0.000003135) none fs_pollfd: { cpu_id = 0 }, { fd = 47 }
[10:42:48.534823479] (+0.000002990) none fs_pollfd: { cpu_id = 0 }, { fd = 48 }
[10:42:48.534826875] (+0.000003396) none fs_pollfd: { cpu_id = 0 }, { fd = 49 }
[10:42:48.534830315] (+0.000003440) none fs_pollfd: { cpu_id = 0 }, { fd = 50 }
[10:42:48.534834449] (+0.000004134) none fs_pollfd: { cpu_id = 0 }, { fd = 51 }
[10:42:48.534837717] (+0.000003268) none fs_pollfd: { cpu_id = 0 }, { fd = 52 }
[10:42:48.534841064] (+0.000003347) none fs_pollfd: { cpu_id = 0 }, { fd = 53 }
[10:42:48.534844754] (+0.000003690) none fs_pollfd: { cpu_id = 0 }, { fd = 54 }
[10:42:48.534849177] (+0.000004423) none fs_pollfd: { cpu_id = 0 }, { fd = 55 }
[10:42:48.534892997] (+0.000043820) none mm_page_free: { cpu_id = 0 }, { pfn = 158205, order = 0 }
[10:42:48.534993555] (+0.000100558) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 716868028, syscall_id = 296 }
[10:42:48.535000284] (+0.000006729) none net_socket_recvmsg: { cpu_id = 0 }, { sock = 0xB5F324E0, msg = 0x983FFF74, size = 2048, flags = 1073741888, ret = 660 }
[10:42:48.535011094] (+0.000010810) none net_socket_sendmsg: { cpu_id = 1 }, { sock = 0xB5CE8B20, msg = 0xB6031F74, size = 463, ret = 463 }
[10:42:48.535013404] (+0.000002310) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 463 }
[10:42:48.535202519] (+0.000189115) none net_socket_recvmsg: { cpu_id = 0 }, { sock = 0xB5F324E0, msg = 0x983FFF74, size = 2048, flags = 1073741888, ret = -11 }
[10:42:48.535231537] (+0.000029018) none kernel_sched_try_wakeup: { cpu_id = 1 }, { pid = 68, cpu_id = 1, state = 256 }
[10:42:48.535243069] (+0.000011532) none kernel_sched_schedule: { cpu_id = 1 }, { prev_pid = 1, next_pid = 68, prev_state = 0 }
[10:42:48.535258092] (+0.000015023) none fs_pollfd: { cpu_id = 1 }, { fd = 5 }
[10:42:48.535264639] (+0.000006547) none fs_pollfd: { cpu_id = 1 }, { fd = 9 }
[10:42:48.535269929] (+0.000005290) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 1 }
[10:42:48.535278789] (+0.000008860) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 717849364, syscall_id = 3 }
[10:42:48.535299225] (+0.000020436) none fs_read: { cpu_id = 1 }, { count = 1, fd = 9 }
[10:42:48.535300645] (+0.000001420) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 0 }
[10:42:48.535306709] (+0.000006064) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 717837844, syscall_id = 240 }
[10:42:48.535309234] (+0.000002525) none fs_ioctl: { cpu_id = 0 }, { fd = 4, cmd = 1075866368, arg = 745629032 }
[10:42:48.535324412] (+0.000015178) none kernel_sched_migrate_task: { cpu_id = 1 }, { pid = 67, state = 256, dest_cpu = 0 }
[10:42:48.535331534] (+0.000007122) none kernel_syscall_exit: { cpu_id = 1 }, { ret = 1 }
[10:42:48.535335210] (+0.000003676) none kernel_syscall_entry: { cpu_id = 1 }, { ip = 718693652, syscall_id = 168 }

Regards,
Jan

> Thanks
> Matthew
> 
> 
> On 13-04-19 06:20 AM, Jan Glauber wrote:
> > Hi list,
> >
> > I've written a converter that can read LTT's 2.6 trace format and convert it
> > to a CTF trace format. This was discussed before on the list:
> >
> > http://lists.lttng.org/pipermail/lttng-dev/2011-June/015995.html
> >
> > and I roughly followed the guidance given by Mathieu there. Roughly because
> > I did not create plugins but followed the approach of babeltrace-log.
> >
> > How it works:
> > - babeltrace legacy converter gets a directory containing a LTT 2.6 trace
> >   and a target directory where it will create the converted trace
> > - it scans the metadata_N files and creates a CTF which fits the old trace data
> > - it scans all trace files and creates CTF headers but copies the trace data
> > - empty files which contain only headers are not copied
> >
> > Is there any interest in picking up this code for babeltrace (or is it just
> > too obscure :) ?
> >
> > Best regards,
> >
> > Jan Glauber
> > Harman Becker Automotive GmbH
> > System Profiling & Optimizing Team
> >
> > Jan Glauber (2):
> >   Resurrect LTT type parser
> >   babeltrace legacy LTT 2.6 -> CTF 1.8 converter
> >
> >  converter/babeltrace-legacy.c        | 1184 ++++++++++++++++++++++++++++++++++
> >  converter/ltt-type-parser.c          |  303 +++++++++
> >  include/babeltrace/ltt-type-parser.h |   17 +
> >  3 files changed, 1504 insertions(+)
> >  create mode 100644 converter/babeltrace-legacy.c
> >  create mode 100644 converter/ltt-type-parser.c
> >  create mode 100644 include/babeltrace/ltt-type-parser.h
> >
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Jan Glauber
---
Harman Becker Automotive GmbH
System Profiling & Optimizing Team

Re: [RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Matthew Khouzam]

Hi Jan,

I have a few questions about the patch:
Does it handle lost events?
I think we would need to bring in a state system for this
Is there a reason lttng2.0 is not working for you? kernel? install base?
other?
Do you want just a list of the events or analysis on the trace later on.

Can you post an example of a converted trace?
Thanks
Matthew


On 13-04-19 06:20 AM, Jan Glauber wrote:
> Hi list,
>
> I've written a converter that can read LTT's 2.6 trace format and convert it
> to a CTF trace format. This was discussed before on the list:
>
> http://lists.lttng.org/pipermail/lttng-dev/2011-June/015995.html
>
> and I roughly followed the guidance given by Mathieu there. Roughly because
> I did not create plugins but followed the approach of babeltrace-log.
>
> How it works:
> - babeltrace legacy converter gets a directory containing a LTT 2.6 trace
>   and a target directory where it will create the converted trace
> - it scans the metadata_N files and creates a CTF which fits the old trace data
> - it scans all trace files and creates CTF headers but copies the trace data
> - empty files which contain only headers are not copied
>
> Is there any interest in picking up this code for babeltrace (or is it just
> too obscure :) ?
>
> Best regards,
>
> Jan Glauber
> Harman Becker Automotive GmbH
> System Profiling & Optimizing Team
>
> Jan Glauber (2):
>   Resurrect LTT type parser
>   babeltrace legacy LTT 2.6 -> CTF 1.8 converter
>
>  converter/babeltrace-legacy.c        | 1184 ++++++++++++++++++++++++++++++++++
>  converter/ltt-type-parser.c          |  303 +++++++++
>  include/babeltrace/ltt-type-parser.h |   17 +
>  3 files changed, 1504 insertions(+)
>  create mode 100644 converter/babeltrace-legacy.c
>  create mode 100644 converter/ltt-type-parser.c
>  create mode 100644 include/babeltrace/ltt-type-parser.h
>

[RFC PATCH 0/2] babeltrace legacy LTT 2.6 converter

[Jan Glauber]

Hi list,

I've written a converter that can read LTT's 2.6 trace format and convert it
to a CTF trace format. This was discussed before on the list:

http://lists.lttng.org/pipermail/lttng-dev/2011-June/015995.html

and I roughly followed the guidance given by Mathieu there. Roughly because
I did not create plugins but followed the approach of babeltrace-log.

How it works:
- babeltrace legacy converter gets a directory containing a LTT 2.6 trace
  and a target directory where it will create the converted trace
- it scans the metadata_N files and creates a CTF which fits the old trace data
- it scans all trace files and creates CTF headers but copies the trace data
- empty files which contain only headers are not copied

Is there any interest in picking up this code for babeltrace (or is it just
too obscure :) ?

Best regards,

Jan Glauber
Harman Becker Automotive GmbH
System Profiling & Optimizing Team

Jan Glauber (2):
  Resurrect LTT type parser
  babeltrace legacy LTT 2.6 -> CTF 1.8 converter

 converter/babeltrace-legacy.c        | 1184 ++++++++++++++++++++++++++++++++++
 converter/ltt-type-parser.c          |  303 +++++++++
 include/babeltrace/ltt-type-parser.h |   17 +
 3 files changed, 1504 insertions(+)
 create mode 100644 converter/babeltrace-legacy.c
 create mode 100644 converter/ltt-type-parser.c
 create mode 100644 include/babeltrace/ltt-type-parser.h

-- 
1.7.9.5