Re: [tracecompass-dev] Trace Compass state snapshot exchange format

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

On 2016-11-08 02:53 PM, Philippe Proulx wrote:
> ----- Original Message -----
>> From: "Matthew Khouzam" <matthew.khouzam@xxxxxxxxxxxx>
>> To: "tracecompass-dev" <tracecompass-dev@xxxxxxxxxxx>
>> Sent: Tuesday, 8 November, 2016 14:15:04
>> Subject: Re: [tracecompass-dev] Trace Compass state snapshot exchange format
> [...]
> `types.json` and `tree.json` could be merged indeed. However, what I
> understand from the state history back-end (and concept) is that the
> association between keys and paths (tree nodes) is an extension (that
> Trace Compass needs, yes), but this would not be required for other
> applications. I suppose this is only interesting if this state history
> API is split from Trace Compass one day. In this case `tree.json` would
> be a TC-specific file (like CTF packet indexes which LTTng adds to
> a CTF trace).
>
>> Also, will it save the segments in the segment store? this is a valid
>> issue as we have several (especially with XML) segment stores being used
>> at this moment. I think we don't want to lose the segments being
>> created. It may be out of scope though for this rfc.
> I'm not qualified to answer this. Alex?

I think it would work well with the history tree as a backend for the
segment store. Unlike "state systems", segment stores do not have
attributes, so by splitting the mapping between attributes (aka paths)
and keys into a separate file, we just skip this file when using a
segment store.

> [...]
>> Finally, the 'history.bin' is not really detailed.

See this as the current *.ht files. The difference we are suggesting is
to break out the last section of that file (the serialized attribute
tree), and put those in separate .json file(s) which can then be re-used
by the statedump.

> [...]
>
>> Could you sell me on why these three files are more interesting that say
>> a json output of the analysis id, the state, and the layout, then it is
>> the responsibility of the analysis to be able to load its snapshot?

Yes, it would be the responsibility of the state-system analysis to load
its own statedump before starting to read trace events. Currently I'm
aiming to add this logic in the TmfStateSystemAnalysisModule.


Cheers,
Alex