On 15/06/2020 16:34, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID
> serialisation is sorted"):
>> Nothing runs it by default, but it is part of my prepush testing for
>> anything in the relevant area.
>>
>> We should do something better, but its not totally trivial. The x86
>> emulator test for example needs a fairly bleeding edge version of
>> binutils, given that we routinely add support for bleeding edge
>> instruction groups.
> Hmmm. Is it likely that installing the version from Debian testing
> (say) would work ? Or do we want to build it from source ? These are
> all possibilities.
Pulling from Sid may work, if they're fairly prompt to update to new
binutils releases. (They're certainly up to date ATM)
Jan: are we ever in a position where we need something more bleeding
edge than the latest binutils release?
>
> We could build binutils from source with a job-specific --prefix
> setting and that wouldn't stop it sharing the build host with other
> jobs. Maybe it could be a seperate job which provides an anointed
> binutils build.
>
> What other awkward requirements are there ?
Most of the tests require running under a suitably configured Xen, and
even then, require doing some fairly custom things with the guest.
Perhaps a good start would be to split our "unit test like" tests away
from our "need a specifically configured Xen" tests. The former would
be rather more amenable to running by default.
~Andrew
