Expose the clock properties in CTFTrace

[siwei-zhang-work]

There is the need to get clock scale of the trace.
This commit added the clock scale to the environment variables of the trace.

[Added] clock scale in getEnvironment() in CTFTrace
[Changed] moved clock offset into getEnvironment() in CTFTrace
[Deprecated] CtfTmfTrace.CLOCK_OFFSET, use CTFTrace.CLOCK_OFFSET instead.

Signed-off-by: Siwei Zhang [email protected]

[MatthewKhouzam]

Hi Siwei, any thoughts on complementing getEnvironment with the frequency? It would require less code and no API changes.

[siwei-zhang-work]

Hi Siwei, any thoughts on complementing getEnvironment with the frequency? It would require less code and no API changes.

But the getEnvironment() refers to a specific env block in the metadata which doesn't include frequency. Also complementing getEnvironment() still requires exposing frequency from the CTFClock. I changed to adding the frequency in the getProperties(), and the frequency is exposed the same way as time offset. Does this seem cleaner? Otherwise I'll add the frequency in the getEnvironment().

[MatthewKhouzam]

getEnvironment currently refers to env but it means all data that is not in events. I would recommend using it for all static information, also I will add get environment to TmfTrace. Trace Event should have this for metadata too. Maybe we can get a second opinion, but I would not add a new api for this instead of enhancing the output.

[siwei-zhang-work]

getEnvironment currently refers to env but it means all data that is not in events. I would recommend using it for all static information, also I will add get environment to TmfTrace. Trace Event should have this for metadata too. Maybe we can get a second opinion, but I would not add a new api for this instead of enhancing the output.

Sounds good, done.

[MatthewKhouzam]

Please make sure you're not breaking the API. @deprecate instead.

[bhufmann]

LGTM. Thanks!