mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-09-11 13:48:30 +09:00
[Fix] (Bench, Trace, CI): let only the profile answer for itself, name an unreadable profile, and describe the CI step by the mechanism the tree has
- The verified-profile guard read the process environment as well as the profile: the test ran after the source, so PROFILE_VERIFIED=1 exported in an operator's shell re-opened the fail-open hole for every profile that says nothing. Both scripts now set PROFILE_VERIFIED=0 immediately before sourcing, so the file is the only thing that can answer. - A --device path that cannot be sourced was diagnosed as an unverified profile, because both scripts cd to their own directory first and neither checked readability. The path is now also tried relative to the directory the script was invoked from (which is what a repo-root-relative --device means), and an unreadable one is reported as unreadable, naming both places tried. - Verified: exported PROFILE_VERIFIED=1 + an unverified profile -> rc 2; exported 1 + a profile with no key -> rc 2; a repo-root-relative path -> resolved, then refused for its own reason; a missing file -> "cannot read the device profile"; odinlite.env -> past the guard; --allow-unverified-profile -> the three warnings, then proceeds. - test.yml's new step described a mechanism the tree does not have. G6's and G10's entries are registered in the pull build too - they must be, for G2's name-for-name comparison - and skip inside their bodies. The step's value is unchanged and its comment now says the true thing: the `test` job runs those names as a column of skips, and this is the first CI job that unpacks a build which compiled the assertions. - trace_benchmark takes the wall baseline before the CPU baseline, the order OnFrameBoundary already reads them in, so frame 0 stops reporting a CPU delta biased upward against its own wall delta; and it includes <time.h> rather than <ctime> for the POSIX names it uses.
This commit is contained in:
@@ -37,6 +37,10 @@ frequency-pin integrity.
|
||||
`--allow-unverified-profile` is passed, which labels the run unpinned in the warning.
|
||||
**A profile that omits the key entirely is refused the same way** - the guard defaults to
|
||||
unverified, so copying a verified profile and editing the serial cannot inherit its verdict.
|
||||
Only the file can answer: both scripts reset `PROFILE_VERIFIED=0` immediately before sourcing
|
||||
it, so `PROFILE_VERIFIED=1` exported in your shell does not re-open the hole. Nor does a
|
||||
profile path that cannot be read get mistaken for an unverified one - it is reported as
|
||||
unreadable, and a path relative to the directory you ran the script from is resolved.
|
||||
(`profile.sh` pins nothing - it records a simpleperf profile - so it carries no such guard.)
|
||||
|
||||
That refusal exists because the pin path is silent when it is wrong: the harness writes
|
||||
|
||||
Reference in New Issue
Block a user