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
