[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/33] Qtest driver framework
Re: [Qemu-devel] [PATCH 00/33] Qtest driver framework
Thu, 16 Aug 2018 20:16:38 +0200
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 15/08/2018 14:38, Markus Armbruster wrote:
You're right, that is the main benefit: running tests in all possible
contexts, with automated context setup.
Before, tests where basically hard-coded to run on a single
architecture, or even a single machine type.
Now, qgraph allows this kind of higher level view of the devices and
their relationships, where tests generally consume an interface that
hides the underneath implementation (for example, for sdhci-pci device,
it consumes a "pci-bus", without knowing that the bus can be a pci-pc or
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
- 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:
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
This allows developers to add test without knowing or forcing the
machine/architecture/additional required devices, they just need to know
what interface the test can consume (and if not present, implement a
node representing the device they want to test).
For example, if you look at virtio-9p-test, you can see that the old
test was just testing "virtio-9p-pci", while using the qgraph I was able
to add "virtio-9p-device" too, without any additional change to the
test, improving test coverage.
The other benefit is the automated context setup: as Paolo said once,
every test basically re-invented the wheel in its own way. Every test
had a main function, a section where qemu was started with proper
devices, and a section where everything was cleaned up and shut down.
Qgraph handles all these operations automatically, so the developer does
not need to care about that. Just add the test function to the graph,
and it will take care of running the test with the proper setup.
Of course this requires a minimal knowledge of the graph and the
relationships you are going to use, since each test will receive
structures representing device from the other nodes in the graph.
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.
Do you think this explanation of the problem is fine?
I am not very experienced with patches, so in case it is, should I
re-write the cover letter adding the above explanations or is fine like
this? In case I should do it, should I submit the whole series again?
- Minor fixes regarding memory leaks and naming
Signed-off-by: Emanuele Giuseppe Esposito <address@hidden>
- [Qemu-devel] [PATCH 26/33] tests/qgraph: virtio-rng test node, (continued)
- [Qemu-devel] [PATCH 26/33] tests/qgraph: virtio-rng test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-devel] [PATCH 30/33] tests/qgraph: virtio-net test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-devel] [PATCH 28/33] tests/qgraph: virtio-blk test node, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-devel] [PATCH 31/33] tests/qgraph: virtio-scsi driver and interface nodes, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-devel] [PATCH 33/33] tests/qgraph: temporarly commented vhost-user-test, Emanuele Giuseppe Esposito, 2018/08/13
- [Qemu-devel] [PATCH 32/33] tests/qgraph: virtio-scsi test node, Emanuele Giuseppe Esposito, 2018/08/13
- Re: [Qemu-devel] [PATCH 00/33] Qtest driver framework, Michael S. Tsirkin, 2018/08/13
- Re: [Qemu-devel] [PATCH 00/33] Qtest driver framework, Markus Armbruster, 2018/08/15
- Re: [Qemu-devel] [PATCH 00/33] Qtest driver framework,