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

[Paolo Bonzini]

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