Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(muxpi): Record the time when the DUT has been rebooted #350

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

thp-canonical
Copy link
Contributor

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 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).

Copy link
Collaborator

@plars plars left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I fully understand how this would be used, since it's getting a timestamp before the hardreset commands are called - which themselves often include a delay which can be different depending on the device. I'm curious why you wouldn't use bootchart or systemd-analyze or something? Or even just logging the time, rebooting, and then getting the difference after boot during the test phase so that it's in a more stable state than it would be during provisioning?

I'm not opposed to it, so please don't take it that way, I just don't think I completely understand the intended use. For it to be useful to anyone, we would need to find a good place to document this and preferably with some tools or examples for making use of it in jobs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants