1: Check the presence of the file 'prefetch_ready'. If it doesn't
exist then the device is booting for the first time after wipe.
Thus, we would just create the file and exit as we do not want
to initiate the record after data wipe primiarly because boot
after data wipe is long and the I/O pattern during first boot may not actually match
with subsequent boot.
2: If the file 'prefetch_ready' is present:
a: Compare the build-finger-print of the device with the one record format
is associated with by reading the file 'build_finger_print'. If they match,
start the prefetch_replay.
b: If they don't match, then the device was updated through OTA. Hence, start
a fresh record and delete the build-finger-print file. This should also cover
the case of device rollback.
c: If the build-finger-print file doesn't exist, then just restart the record
from scratch.
Bug: 362507272
Test: Prefetch record/replay
Change-Id: I90b861ba9381ddba6ab7dedb9930a735e55b0e5d
Signed-off-by: Akilesh Kailash <akailash@google.com>
1: This supports "mem" tracing only.
2: Replay option is modified to use "pread" instead
of readahead.
A simple utility binary "prefetch" is built which links to the library.
The binary allows record, replay and verifying the generated
metadata.
Bug: 362507272
Test: cargo test passes all unit tests.
Verify record, replay and dump options:
./prefetch record --duration 10 --path /data/test/trace-test
./prefetch replay --path /data/test/trace-test
./prefetch dump /data/test/trace-test --format csv
Change-Id: I1661e49183c6120d2878510e609571fe6d608bb5
Signed-off-by: Vikram Auradkar <auradkar@google.com>
Signed-off-by: Akilesh Kailash <akailash@google.com>
