[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[linuxtools-dev] FW: [cdt-dev] TCF 1.0 vs 0.40

-----Original Message-----
From: Dominique Toupin 
Sent: May-04-12 3:29 PM
To: CDT General developers list.
Cc: Doug Schaefer
Subject: RE: [cdt-dev] TCF 1.0 vs 0.40

Hi Jeff,

Lttng has not recently switched to use TCF, we did a prototype a few years ago but it was not conclusive.
LTTng 2.0 and the corresponding Eclipse integration do not use TCF, we instead want to improve the GDB, LTTng, etc. remote protocol and use that in 2013, so we do not plan on using TCF in the future.

You might be confused with CTF, it is quite confusing because it is the same letters, but it means the Common Trace Format, it was done with the Linux CE workgroup and the multicore association. CTF has been implemented in LTTng 2.0, in the Eclipse trace viewer, for HW tracing, etc.

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff Johnston
Sent: May-01-12 5:07 PM
To: CDT General developers list.
Cc: Doug Schaefer
Subject: [cdt-dev] TCF 1.0 vs 0.40

I am confused about the state of TCF.

CDT ships TCF 0.4.0 which was needed by Linux Tools Lttng.

There is work going on for TCF 1.0.  I am not certain whether this is supposed to be its own project or if it is still under the CDT umbrella.

That said, David Williams is not aware of TCF having applied to be part of the Juno train as its own project and it is too late for an exception.

Lttng has recently switched to use the new TCF 1.0 APIs, but no one ships that.

Can the CDT ship new versions of those TCF features (which have
refactored) as part of an upgrade to an existing component?  If no, it means that Lttng has to revert those changes for Juno M7 and go back to using TCF 0.4.0 that is still supplied by the CDT's b3aggrcon.

-- Jeff J.
cdt-dev mailing list