qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/7] Qtest driver framework


From: Emanuele
Subject: Re: [Qemu-devel] [PATCH 0/7] Qtest driver framework
Date: Wed, 11 Jul 2018 16:17:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/11/2018 04:00 PM, Stefan Hajnoczi wrote:

On Mon, Jul 09, 2018 at 11:11:29AM +0200, Emanuele Giuseppe Esposito wrote:
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 drivers
   and machines
QEMU doesn't know about qtest drivers.  Does "drivers" mean "devices"
(i.e. qemu -device \?) and they have a 1:1 correspondence with qtest
drivers?
Yes, they are QEMU devices, it was a typo.
Not all qtest drivers are mapped with the QEMU devices, though. In fact, for now all drivers "contained" or "produced" by other nodes are not QEMU devices.

The others (machines and nodes that "consume"), are mapped to QEMU using the
{ "execute": "qom-list-types", "arguments" : { "implements" : "device" } }
for "consume" and
{ "execute": "query-machines" }
for machines.

With "consume" I mean in situation like "node X" ---> consumes --> "node Y",
"X" should be in the output of qom-list-types query.
The concept of qgraph makes sense.  Ease of use and documentation will
be critical to gain adoption.  The extra complexity makes it hard for
people writing and running tests, so it's important that it's clear
which tests will get run and why (or why not).
I am trying to document and makes it as easy and clean as possible :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]