Closed bjackman closed 6 years ago
Trappy isn't my turf but the code LGTM. Update logic is sound to me too, I just have a question regarding the trace.txt handling.
IIUC, Trappy will now read a trace.dat file and create a trace.trappy.txt file for parsing. If trace.dat is not here but trace.trappy.txt is, warn and continue - so far so good. However, I don't get where the trace.txt is coming from. Is that just legacy support ? We're not supposed to generate any trace.txt file anymore, right ?
However, I don't get where the trace.txt is coming from. Is that just legacy support ? We're not supposed to generate any trace.txt file anymore, right ?
Yeah, legacy support and so that users who know what they're doing and want to create textual traces (using the correct trace-cmd args) can still use them.
Yeah, legacy support and so that users who know what they're doing and want to create textual traces (using the correct trace-cmd args) can still use them.
Okay, it all LGTM then.
This is superseded by the superior https://github.com/ARM-software/trappy/pull/270, because that PR means we stop parsing trace.txt unless it's the only thing we have.
TRAPpy requires that trace.txt files are created with certain events printed raw, rather than formated. When given a trace.dat, it currently creates a trace.txt that fits that requirement, then uses that for parsing.
It used to create one trace.txt with non-raw formatting, and a trace.raw.txt with raw formatting. Therefore it currently uses the presence of trace.raw.txt as a hint to suggest that the trace.txt contains non-raw formatting (as created by an older version of TRAPpy), and raises an error in this case.
However bad (non-raw) trace.txt files may have been created by the user or other tools such as Workload Automation[1].
Therefore, this patch presents a new approach to finding and creating input files:
Ignore trace.raw.text
When given a trace.dat file, convert it to a trace.trappy.txt file with all the required events formatted as raw (unless this has already been done). We can hope that this file is not created by any other tool.
When the trace.dat is not present but a trace.trappy.txt is present, assume that TRAPpy created the trace.trappy.txt and that the user has since deleted the corresponding trace.dat. Warn, and continue using trace.trappy.txt.
If only a trace.txt is present, warn the user (because there are likely non-raw events in it, in which case we cannot recover and will crash cryptically), but continue anyway, so that if the user has manually created a correctly formatted trace.txt then they can still use that.
[1] https://github.com/ARM-software/workload-automation