valschneider
commented
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 ?
bjackman
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