Re: [Qemu-devel] [PATCH for-2.0 v2] tests: Don't run qom-test twice

[Andreas Färber]

Am 24.04.2014 16:34, schrieb Peter Maydell:
> On 24 April 2014 15:29, Stefan Hajnoczi <address@hidden> wrote:
>> On Mon, Apr 07, 2014 at 04:13:00PM +0200, Andreas Färber wrote:
>>> Commit 3687d5325 accidentally resulted in running qom-test twice
>>> for x86_64, once directly via the wildcard, and once because x86_64
>>> includes all the i386 qtests (which includes qom-test).
>>>
>>> Filter out x86_64 as well as microblazeel and xtensaeb to fix this.
>>>
>>> Cc: Peter Maydell <address@hidden>
>>> Signed-off-by: Andreas Färber <address@hidden>
>>> ---
>>>  v1 (PMM) -> v2:
>>>  * Instead of sorting all qtests, leave the order intact and just filter
>>>    the three affected architectures out.
>>>
>>>  tests/Makefile | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> Didn't make it into 2.0 but...
>>
>> Reviewed-by: Stefan Hajnoczi <address@hidden>
> 
> Personally I prefer the "just sort-and-uniquify"
> approach. This patch introduces an explicit list of
> architectures which need to be special case, which
> means that if we ever add a future arch variant which
> also needs this special casing we need to update the
> list. The sort patch doesn't have this requirement --
> it will just work for both this and for any other
> reason why we might end up with a test in the list
> multiple times.

Your dislike is why I didn't apply it for 2.0. However, a) the
inheritance of tests for these three architectures is already an
explicit statement in the Makefile and more severely b) by sorting the
list, tests newly added get lost in the gcov stdout chatter (leading to
even less verification of correctness) and we cannot sensibly order
tests to first cover, say, PCI host bridge and then PCI devices
depending on it.

I already asked you for an alternative way of automatically stripping
duplicates without changing their order, to no avail.

What about defining some macro to replace the old hand-coded "reuse
tests" bits and automatically put that arch into an exclusion list?
If someone does add a test twice then I'd rather catch and fix that.

Alternatively a) would be nicely solvable by being able to run tests
individually rather than just at check-qtest-$arch granularity.
No clue about that part of the gtester/Makefile infrastructure really;
there's also a patch from Stefan that didn't make it into 2.0 due to me
wondering whether it is the right thing to do or not:
http://patchwork.ozlabs.org/patch/329820/
(The obvious issue being that it drops the architecture.)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg