Hi Aleksandar,
On 1/21/19 11:15 PM, Aleksandar Markovic wrote:
>> From: Cleber Rosa <cr...@redhat.com>
>
>> class My(Test):
>> def test_nx_cpu_flag(self):
>> """
>> :avocado: tags=arch:x86_64
>> """
>> test_code()
>
>> The value of the "arch" key, in this case, "x86_64" will be used when
>> selecting the QEMU binary to use in the test. At the same time, if
>> "x86_64-softmmu" is not a built target, the test will be filtered out
>> by "make check-acceptance"[3].
>
> I think, the term "arch" is a little problematic in QEMU parlance. IMHO,
> "target" should be used instead. ("arch" is used in Linux kernel community)
Using target_arch/host_arch might be more explicit, but host_arch is not
very relevant regarding Avocado (except to choose the correct TCG
binary), so usually arch implies target_arch.
I mean, it is unlikely you enforce --host_arch on the command line to
run tests, this using --arch instead of --target_arch looks OK to me,
since host_arch can be guessed.
>
> The overall structure of the "tags" should be a little different. My
> suggestion:
>
> "target"
> "isa" (instruction set architecture, determeines how the kernel and rootfs
> are built)
In QEMU, "isa" is implicit with CPU, isnt' it?
I.e. I use:
$ mips64el-softmmu/qemu-system-mips64el -M Malta -cpu mips64dspr2
> "cpu"
> "machine"
>
> This would allow clear view what a particular acceptance test tests, and will
> enforce consistency and clarity in the test organization across the board.
Maybe the problem you are pointing out is not Avocado test organization
but QEMU CPU organization... (which also bother me with boards able to
use different SoC, with different peripherals or cpus).
What is your idea on passing arch/cpu/isa to start QEMU?
>
> That said, I am very excited about this series.
Me too :)
Regards,
Phil.
