Re: [PATCH 08/12] tests/9pfs: refactor test names and test devices

[Christian Schoenebeck]

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