From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
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: Thu, 01 Oct 2020 14:15:05 +0200 [thread overview]
Message-ID: <12227378.mPQFScNTDJ@silver> (raw)
In-Reply-To: <d6f5cc89-bdac-13a9-d7bc-c7b63a10da79@redhat.com>
On Donnerstag, 1. Oktober 2020 13:56:42 CEST Paolo Bonzini wrote:
> On 01/10/20 13:34, Christian Schoenebeck wrote:
> > Paolo, I'm back at square one after changing to single-device model as you
> > suggested:
> >
> > GTest: run:
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/pci-
> > device/pci-device-tests/nop
> > Run QEMU with: '-M pc -device virtio-9p-pci'
> > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest
> > unix:/tmp/ qtest-18032.sock -qtest-log /dev/null -chardev
> > socket,path=/tmp/
> > qtest-18032.qmp,id=char0 -mon chardev=char0,mode=control -display none -M
> > pc -device virtio-9p-pci -accel qtest)
> > qemu-system-x86_64: -device virtio-9p-pci: 9pfs device couldn't find fsdev
> > with the id = NULL
> > Broken pipe
> >
> > This fundamental virtio-9p-pci test obviously needs a complete 9p command
> > line, that is either a 'synth' driver one, or a 'local' one. But simply
> > either picking one or another is inappropriate here. This test should run
> > once for 'synth' and once for 'local'.
>
> You're right, this is in fact also a problem for virtio-blk and virtio-net:
>
> /* FIXME: every test using these two nodes needs to setup a
> * -drive,id=drive0 otherwise QEMU is not going to start.
> * Therefore, we do not include "produces" edge for virtio
> * and pci-device yet.
> */
>
> /* FIXME: every test using these nodes needs to setup a
> * -netdev socket,id=hs0 otherwise QEMU is not going to start.
> * Therefore, we do not include "produces" edge for virtio
> * and pci-device yet.
> */
>
> I still think we should do it like this, because it's closer to the way
> that libqos will work long term.
Could you please elaborate why that long term plan bites with the working
solution I provided? [patches 1 and 2]
I mean, the solution I suggested is simple and working. I don't see a reason
why that should be incompatible with future plans. IMO it makes sense to use
the suggested solution instead of dropping tests just because of potential qos
changes somewhere in far future that might happen or not. It is still a qos
design limitation after all that must be addressed sooner or later. So also a
future qos design must deal with this in some way.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-10-01 12:17 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
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 [this message]
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=12227378.mPQFScNTDJ@silver \
--to=qemu_oss@crudebyte.com \
--cc=e.emanuelegiuseppe@gmail.com \
--cc=groug@kaod.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--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).