qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/33] virtio, pc: fixes and features


From: Sascha Silbe
Subject: Re: [Qemu-devel] [PULL 00/33] virtio, pc: fixes and features
Date: Tue, 11 Oct 2016 13:54:27 +0200
User-agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)

Dear Thomas,

Thomas Huth <address@hidden> writes:

> On 11.10.2016 10:27, Sascha Silbe wrote:
[pxe-test failing during "make check"]
>> There's a race condition in the tests. Both the "i386" and the "x86_64"
>> set of tests are creating and removing the same set of files:
>> tests/acpi-test-disk.raw (hard-coded in tests/bios-tables-test.c) and
>> tests/pxe-test-disk.raw (hard-coded in tests/pxe-test.c).
>
> Hmm, it's likely even worse - the new ppc64 test is using the same file
> name, too - with different content in the file. So if the tests are
> running in parallel, they will likely disturb each other.

Ouch.

> I think we should use mkstemp() instead for creating a unique file. Is
> anybody working on a patch already? If not, I could have a look...

Feel free to go ahead. In the long run we'll probably want a more
systematic approach; I've fixed several instances in the past (see
50455700, 5f1525a6, 6bb6f6cd, 0145b4e1). But that shouldn't prevent us
From fixing a known issue in the meantime.


>> FWIW, it's not obvious at first sight that the tests added to
>> check-qtest-i386-y will also be included in check-qtest-x86_64-y. The
>> line responsible for that is hiding in the midst of other assignments,
>> without even a blank line separating it from the rest.
>> 
>> Assigning to a common variable first and then including it in both
>> check-qtest-i386-y and check-qtest-x86_64-y would make it a lot easier
>> to understand IMO.
>
> Could you maybe provide a patch for this, Sascha? (at least for adding
> some blank lines inbetween - currently it is really hard to read)

I'll try to whip up a patch in the next few days. Unless someone has a
strong preference to stay with the current scheme, I'll implement the
common variable approach I outlined above.

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr.: DE281696641

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]