This is a proposal for creating a timestamp file at the time where the DUT is rebooted, so that tests that want to measure boot times will have a reference timestamp.
With this change, the testing code can stat(2) the file and compare the st_mtim to the current time and get a better estimate of the full boot time (including low-level boot loaders, second-stage boot loaders and early kernel loading).
Using e.g. the device's uptime wouldn't take early bootloader stages into account, hence if those stages take too long, this isn't captured with uptime, so having the time when the device was "powered on" (hard-reset) would be good.
This is just an implementation proposal, it might be that such facilities already exist.
Resolved issues
-
Documentation
Not documented at the moment.
Web service API changes
None.
Tests
This has not been tested. I also haven't checked if the file would be cleared when a new provisioning session is started (it might be that we need to force-delete an existing file if it exists).
Description
This is a proposal for creating a timestamp file at the time where the DUT is rebooted, so that tests that want to measure boot times will have a reference timestamp.
With this change, the testing code can
stat(2)the file and compare thest_mtimto the current time and get a better estimate of the full boot time (including low-level boot loaders, second-stage boot loaders and early kernel loading).Using e.g. the device's uptime wouldn't take early bootloader stages into account, hence if those stages take too long, this isn't captured with uptime, so having the time when the device was "powered on" (hard-reset) would be good.
This is just an implementation proposal, it might be that such facilities already exist.
Resolved issues
-
Documentation
Not documented at the moment.
Web service API changes
None.
Tests
This has not been tested. I also haven't checked if the file would be cleared when a new provisioning session is started (it might be that we need to force-delete an existing file if it exists).