| Re: [tracecompass-dev] Trace Compass state snapshot exchange format |
On 2016-11-08 04:34 PM, Matthew Khouzam wrote: > So basically what you are proposing is to pull out the metadata (node > tree and types) from the interval tree and then have all three. Something like that, yes, but that's the long-term "1.0" proposal: intervals.bin tree.json types.json The segment store would skip tree.json completely. And for statedumps, we can copy over tree.json and types.json directly. Initially we would just make a "0.x" spec for the statedump, which is a single JSON file that has the tree hierarchy, the types, and the state values in it. > What is the advantage of doing so vs keeping it as is and making a > diminutive state system then can then be merged or resumed? As we discussed on IRC, the statedump is a list of state values, not intervals. It is not necessary - or even desired - to restore the intervals' start times. End times will be recomputed by the analysis when re-reading the trace events. Also, I think it's good to differentiate a "statedump" from a "state system". The latter is produced by the viewer and becomes a supplementary file, meaning it can be rebuilt from the trace at any time. The former, on the other hand, should become part of the trace. If we lose the statedump, we lose information. This is why, in the code I'm working on, the statedump is saved in the same directory as the trace, and not as supplementary files. Cheers, Alex > > On 16-11-08 04:17 PM, Alexandre Montplaisir wrote: >> 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 >> >>
Attachment:
signature.asc
Description: OpenPGP digital signature