On 22.02.19 12:51, Paolo Bonzini wrote: > On 22/02/19 11:30, Stefan Raspl wrote: >> Yeah, that would be nice. Took a stab at it, but realized this might not be so >> easy: Since testcases can be executed in parallel, we'd have to implement some >> kind of locking of the testcase counter. In bash. I couldn't find any way to >> implement that. >> Any guidance...? > > One possibility could be to use Make to coordinate the tests instead of > bash. The Makefile, generated via for_each_unittest, would look like > > all: > > all: logs/foo.log > logs/foo.log: > ./run_one_test.sh ... | tee logs/foo.log | ./logs-to-tap.sh > > all: logs/bar.log > logs/fobar.log: > ./run_one_test.sh ... | tee logs/bar.log | ./logs-to-tap.sh > > (or ./logs-to-summary.sh in non-TAP mode) > > where run_one_test.sh would basically be the "run_task" function of > run_test.sh. Simplifications would also be possible by dropping > RUNTIME_log_stdout and RUNTIME_log_stderr > > Then in run_tests.sh you can use the scripts/tap-merge.pl file from QEMU > to create a single TAP file. > > But if all the output is done at the end of the run, why do you need to > do it in run-tests.sh at all? You can just get the combined TAP output > from logs/ after the fact. So the simplest way to go, would be to > change this patch into a standalone logs-to-tap.sh scripts. The idea is that we keep TAP13 integrated with the other command line options. For convenience, consistency, etc. Not sure if folks would look elsewhere for yet another script that post-processes output to provide functionality that was available as a mere command line option in the first place. Plus this has the added value of keeping all the code for TAP13 close to the rest - if we separate it out elsewhere, the danger of changes breaking TAP13 output inadvertently increases. I tried doing things with a rather coarse flock() at the end of the run() function - but that doesn't work: Since we're starting each invocation of run() in a separate process when '-j' is specified, concurrent updates of the counter variable are not visible in the other processes :/ And I would assume that the approach outlined above using a generated Makefile might suffer from the same fate. I believe I found a workable approach now - I'll repost... Ciao, Stefan
