On Mon, Mar 7, 2022 at 12:56 PM Joseph, Jithu <jithu.joseph@xxxxxxxxx> wrote: > > > > On 3/7/2022 12:25 PM, Dan Williams wrote: > > > > > I am speaking of the state of the case where 2 threads are doing > > run_test and polling for results. Unless you can guarantee that run2 > > does not start before the results of run1 have been collected then > > they are lost in that scenario. No amount of kernel locking can > > resolve that race to collect previous result which would not be a > > problem in the first place if there was an atomic way to log test > > results. > > > Yes "status" shows the status of the latest run. You cannot get the status of the previous run. > > Also some context on test frequency: Hardware has strict rate limiting of tests. > Every core can be tested only once in every 30 minutes. So it is pointless to test at high frequency. Is that enforced in the ABI? Did I miss that detail in the documentation? Does that per-core time limitation also mitigate the race to read the global status? I.e. back-to-back tests on the same core may need to be spaced by 30 minutes, but between different cores as well. Again, these are questions that can not even be posed with an ABI that eliminates the possibility of result races like uevent. Please think through that suggestion, that's my main motivation for continuing to poke at this ABI as currently presented.
