From: Paolo Bonzini <pbonzini@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>, qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>,
Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH 08/12] tests/9pfs: refactor test names and test devices
Date: Mon, 28 Sep 2020 14:42:48 +0200 [thread overview]
Message-ID: <95ef57d0-b35e-f16a-f957-06bc3692cb7c@redhat.com> (raw)
In-Reply-To: <3365834.oEZqtqHOuS@silver>
On 28/09/20 13:56, Christian Schoenebeck wrote:
>> The implementation in patches 1 and 2 is reasonable, but what is the
>> advantage of this as opposed to specifying the fsdev in the edge options
>> for the test (similar to virtio-net)? I was expecting both
>> virtio-9p-device-synth and virtio-9p-device-local to produce virtio-9p,
>> so that the existing tests would be reused automatically by the qos
>> graph walk.
>>
>> As things stand, I don't see any reason to have separate devices for
>> different backends.
>
> I thought to fix the problem at its root, by removing that singular device
> limitation in qos. That would also allow to cleanly separate tests suites that
> are not related to each other instead of having to depend on each other,
> taking care about other one's command line skeleton and more.
As I said, the first two patches make total sense. They would be useful
for testing both packed and split virtqueues, for example. However, I
think the (useful) feature is being misused here.
> So your suggested solution is fine for appending extra arguments past the
> command line. However I would not be able to prepend something (easily) in
> front of '-device virtio-9p-pci'.
>
> So I would be forced to parse the existing command line in modifycmdline()
> callback and then insert the required arguments appropriately. I would not
> find that very clean.
IIRC -fsdev can be added to the end of the command line and it still
works. But if you think that is ugly, you can also use g_string_prepend.
Also, looking at future plans for qgraph, adding a generic "plug/socket"
mechanism to QOSGraph was an idea that we couldn't do in time for GSoC.
With that model, virtio-9p would provide a "socket" of type fsdev and
the tests would have to provide a "plug" of the same type. Likewise
there would be sockets of type disk or network. QOSGraphEdgeOpts fits
better with that plan, compared to duplicating the devices.
Paolo
next prev parent reply other threads:[~2020-09-28 13:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-27 10:43 [PATCH 00/12] 9pfs: add tests using local fs driver Christian Schoenebeck
2020-09-27 10:38 ` [PATCH 01/12] tests/qtest/qgraph: add qemu_name to QOSGraphNode Christian Schoenebeck
2020-09-27 10:39 ` [PATCH 02/12] tests/qtest/qgraph: add qos_node_create_driver_named() Christian Schoenebeck
2020-09-27 10:39 ` [PATCH 03/12] tests/qtest/qos: add qos_dump_graph() Christian Schoenebeck
2020-09-27 10:39 ` [PATCH 04/12] tests/qtest/qos-test: new QTEST_DUMP_GRAPH environment variable Christian Schoenebeck
2020-09-27 10:39 ` [PATCH 05/12] tests/qtest/qos-test: add QTEST_DUMP_ENV " Christian Schoenebeck
2020-09-27 10:40 ` [PATCH 06/12] tests/qtest/qos-test: add environment variable QTEST_DEBUG Christian Schoenebeck
2020-09-28 8:31 ` Paolo Bonzini
2020-09-28 12:11 ` Christian Schoenebeck
2020-09-27 10:40 ` [PATCH 07/12] test/9pfs: change export tag name to qtest-synth Christian Schoenebeck
2020-09-27 10:40 ` [PATCH 08/12] tests/9pfs: refactor test names and test devices Christian Schoenebeck
2020-09-28 8:36 ` Paolo Bonzini
2020-09-28 8:37 ` Paolo Bonzini
2020-09-28 11:56 ` Christian Schoenebeck
2020-09-28 12:42 ` Paolo Bonzini [this message]
2020-09-28 13:35 ` Christian Schoenebeck
2020-09-28 16:38 ` Paolo Bonzini
2020-10-01 11:34 ` Christian Schoenebeck
2020-10-01 11:56 ` Paolo Bonzini
2020-10-01 12:15 ` Christian Schoenebeck
2020-10-01 14:04 ` Paolo Bonzini
2020-10-01 15:26 ` Christian Schoenebeck
2020-09-27 10:40 ` [PATCH 09/12] tests/9pfs: introduce local tests Christian Schoenebeck
2020-09-27 10:41 ` [PATCH 10/12] tests/9pfs: wipe local 9pfs test directory Christian Schoenebeck
2020-09-27 10:41 ` [PATCH 11/12] tests/9pfs: add virtio_9p_test_path() Christian Schoenebeck
2020-09-27 10:41 ` [PATCH 12/12] tests/9pfs: add local Tmkdir test Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95ef57d0-b35e-f16a-f957-06bc3692cb7c@redhat.com \
--to=pbonzini@redhat.com \
--cc=e.emanuelegiuseppe@gmail.com \
--cc=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).