On Donnerstag, 1. Oktober 2020 16:04:39 CEST Paolo Bonzini wrote: > >> 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] > > Because the long term plan is to have a socket/plug mechanism for > backends where the device can provide a default backend to plug.
Ok, obviously I don't know the details of that future socket/plug plan, but what I could also imagine for the long-term: allowing to optionally define 'config' nodes as subnodes of devices. Maybe that's similar to what you had in mind with that socket/plug model. > The suggested solution is all good for *a different use case*, namely to > test the same device with different options. It is just wrong for the > purpose of selecting a frontend. > > It occurred to me that you could also add a default backend to the > command line with "-fsdev" (in the libqos driver), and use -set in the > test to override it. This is ugly (-set is ugly!) but it would let you > keep the tests, so it would probably be the best solution. Ok, I'll have a look at that '*-set' alternative tomorrow. But on doubt: I will simply disable those the implied pci and virtio tests for the time being. I need the 'local' backend tests and have to move on; they are of much more value than those 2 implied pci and virtio tests. Best regards, Christian Schoenebeck
