beb6b57b3b
move python/qemu/*.py to python/qemu/[machine, qmp, utils]/*.py and update import directives across the tree. This is done to create a PEP420 namespace package, in which we may create subpackages. To do this, the namespace directory ("qemu") should not have any modules in it. Those files will go into new 'machine', 'qmp' and 'utils' subpackages instead. Implement machine/__init__.py making the top-level classes and functions from its various modules available directly inside the package. Change qmp.py to qmp/__init__.py similarly, such that all of the useful QMP library classes are available directly from "qemu.qmp" instead of "qemu.qmp.qmp". Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-10-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com> |
||
---|---|---|
.. | ||
avocado_qemu | ||
virtiofs_submounts.py.data | ||
boot_linux_console.py | ||
boot_linux.py | ||
boot_xen.py | ||
cpu_queries.py | ||
empty_cpu_model.py | ||
hotplug_cpu.py | ||
info_usernet.py | ||
linux_initrd.py | ||
linux_ssh_mips_malta.py | ||
machine_arm_canona1100.py | ||
machine_arm_integratorcp.py | ||
machine_arm_n8x0.py | ||
machine_avr6.py | ||
machine_m68k_nextcube.py | ||
machine_microblaze.py | ||
machine_mips_loongson3v.py | ||
machine_mips_malta.py | ||
machine_ppc.py | ||
machine_rx_gdbsim.py | ||
machine_s390_ccw_virtio.py | ||
machine_sparc64_sun4u.py | ||
machine_sparc_leon3.py | ||
migration.py | ||
multiprocess.py | ||
pc_cpu_hotplug_props.py | ||
ppc_prep_40p.py | ||
README.rst | ||
replay_kernel.py | ||
reverse_debugging.py | ||
tcg_plugins.py | ||
tesseract_utils.py | ||
version.py | ||
virtio_check_params.py | ||
virtio_version.py | ||
virtio-gpu.py | ||
virtiofs_submounts.py | ||
vnc.py | ||
x86_cpu_model_versions.py |
============================================ Acceptance tests using the Avocado Framework ============================================ This directory contains functional tests, also known as acceptance level tests. They're usually higher level, and may interact with external resources and with various guest operating systems. For more information, please refer to ``docs/devel/testing.rst``, section "Acceptance tests using the Avocado Framework".