[Avocado-devel] Representing QEMU features on multiplexer tree

[Eduardo Habkost]

Hi,

I'm trying to find my way through yaml_to_mux, and looking for
recommendations on how to represent QEMU features in the Avocado
multiplexer tree.


Problem statement
-----------------

Assuming I have the following QEMU binaries:

qemu-system-x86_64:
  supports machine-types: pc, q35, none
qemu-system-ppc64:
  supports machine-types: pseries, prep, none

I want to run the following test cases with a few variants:

Test 1:
  Will test all machine-types on all QEMU binaries

Test 2:
  Will test all machine-types except "none"

In other words, I want to generate the following test variants:

For Test 1:
  qemu_bin=qemu-system-x86_64, machine=pc
  qemu_bin=qemu-system-x86_64, machine=q35
  qemu_bin=qemu-system-x86_64, machine=none
  qemu_bin=qemu-system-ppc64, machine=pseries
  qemu_bin=qemu-system-ppc64, machine=prep
  qemu_bin=qemu-system-ppc64, machine=none

For Test 2:
  qemu_bin=qemu-system-x86_64, machine=pc
  qemu_bin=qemu-system-x86_64, machine=q35
  qemu_bin=qemu-system-ppc64, machine=pseries
  qemu_bin=qemu-system-ppc64, machine=prep


The solution I have tried
-------------------------

I have generated the following YAML file (variants.yaml):

  arch: !mux
    x86_64:
      qemu_bin: qemu-system-x86_64
      machine: !mux
        none: {machine: none}
        pc: {machine: pc}
        q35: {machine: q35}
    ppc64:
      qemu_bin: qemu-system-ppc64
      machine: !mux
        none: {machine: none}
        prep: {machine: prep}
        pseries: {machine: pseries}

Then I thought I could do this on a test2.yaml file:

  !include : 'variants.yaml'
  !filter-out : /machine/none

But this won't work, because "-machine none" is represented by a
different path on each architecture (/arch/x86_64/machine/none vs
/arch/ppc64/machine/none).

Is there a way to place the machine-type name always under
"/machine" (not /arch/.../machine), but generate a different set
of values for /machine for each QEMU binary?

Maybe I'm misguided and is there a better way to encode the
information above?

-- 
Eduardo