[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/33] Qtest driver framework
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/33] Qtest driver framework |
Date: |
Wed, 15 Aug 2018 14:38:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Emanuele Giuseppe Esposito <address@hidden> writes:
> Qgraph API for the qtest driver framework
>
> This series of patches introduce a different qtest driver
> organization, viewing machines, drivers and tests as node in a
> graph, each having one or multiple edges relations.
>
> The idea is to have a framework where each test asks for a specific
> driver, and the framework takes care of allocating the proper devices
> required and passing the correct command line arguments to QEMU.
>
> A node can be of four types:
> - MACHINE: for example "arm/raspi2"
> - DRIVER: for example "generic-sdhci"
> - INTERFACE: for example "sdhci" (interface for all "-sdhci" drivers)
> - TEST: for example "sdhci-test", consumes an interface and tests
> the functions provided
>
> An edge relation between two nodes (drivers or machines) X and Y can be:
> - X CONSUMES Y: Y can be plugged into X
> - X PRODUCES Y: X provides the interface Y
> - X CONTAINS Y: Y is part of X component
>
> Basic framework steps are the following:
> - All nodes and edges are created in their respective machine/driver/test
> files
> - The framework starts QEMU and asks for a list of available devices
> and machines
> - The framework walks the graph starting from the available machines and
> performs a Depth First Search for tests
> - Once a test is found, the path is walked again and all drivers are
> allocated accordingly and the final interface is passed to the test
> - The test is executed
> - Unused objects are cleaned and the path discovery is continued
>
> Depending on the QEMU binary used, only some drivers/machines will be
> available
> and only test that are reached by them will be executed.
>
> This work is being done as Google Summer of Code 2018 project for QEMU,
> my mentors are Paolo Bonzini and Laurent Vivier.
> Additional infos on the project can be found at:
> https://wiki.qemu.org/Features/qtest_driver_framework
You've likely answered this question somewhere already, but it should be
answered right here: what does this framework buy us?
I figure the main benefit is running tests in all possible contexts,
with automated context setup. Instead, you feed the framework
declarations of how things are related (the graph stuff described
above).
Taking a step back: your cover letter describes a solution at a high
level. That's good. But it should *first* describe the problem you're
trying to solve.
> v3:
> - Minor fixes regarding memory leaks and naming
>
> Signed-off-by: Emanuele Giuseppe Esposito <address@hidden>
- Re: [Qemu-ppc] [PATCH 33/33] tests/qgraph: temporarly commented vhost-user-test, (continued)
- [Qemu-ppc] [PATCH 25/33] tests/qgraph: virtio-rng driver and interface nodes, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 26/33] tests/qgraph: virtio-rng test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 30/33] tests/qgraph: virtio-net test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 31/33] tests/qgraph: virtio-scsi driver and interface nodes, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 32/33] tests/qgraph: virtio-scsi test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 02/33] tests/qgraph: rename qpci_init_pc and qpci_init_spapr functions, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 03/33] tests/qgraph: pci-pc driver and interface nodes, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 07/33] tests/qgraph: arm/raspi2 machine node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-ppc] [PATCH 09/33] tests/qgraph: ppc64/pseries machine node, Emanuele Giuseppe Esposito, 2018/08/13
- Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/33] Qtest driver framework,
Markus Armbruster <=