Re: [libvirt] [PATCH v2] vhost-user: define conventions for vhost-user backends

On Wed, Oct 31, 2018 at 07:44:36PM +0400, Marc-André Lureau wrote: > Hi > > On Tue, Oct 16, 2018 at 4:14 PM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > > > It just reinvents the chardev unix socket syntax, but in a > > > > different adhoc manner, which is repeating the mistake we have > > > > made time & again in QEMU. Using QAPI we can directly accept > > > > the ChardevSocket syntax we already know about. Instead of > > > > having --socket-path and --fd and documenting that they are > > > > mutually exclusive ChardevSocket QAPI schema provides that > > > > representation in a well defined format which is discoverable > > > > and QEMU and mgmt apps already understand. > > > > > > That would require external vhost-user backends to implement QAPI/json > > > parsing. Is this necessary for a vhost-user backend? I doubt it. > > > > They could, but would not be required, to implement QAPI/json parser. > > > > The QAPI schema defines a standard for how to model & interpret the > > non-scalar values for command line arguments. An external impl would > > need to ensure that whatever parsing it does for CLI args is semantically > > compatible with the parsing rules defined by the QEMU QAPI schema we > > define to ensure interoperability of its impl. > > So you would want to have something like? > > --chardev '{ "id" : "bar", "backend" : { "type" : "socket", "data" : { > "addr" : { "type": "unix", "path": "/tmp/foo.sock" }, "server": > "false" } } }' I wasn't specificially suggesting json syntax. Just the flattened dot separate syntax, whose valid components are mapped to corresponding qapi schema defintions. eg closer to what we have already today --chardev socket,id=bar,path=/tmp/foo.sock,server

> > instead of: > > --socket-path=/tmp/foo.sock > > I don't really get what that will help with, for the vhost-user backend case... It avoids presuming that we forever want to launch the backend with a single socket path and nothing else. Using the chardev, means we can choosen between client/server mode. We can choose whether to pass an FD to the socket, instead of the socket path. Whether the reconnect flag is set or not, and all the other aspects of a chardev you can define.

I don't think we should have to add more & more adhoc CLI args (--socket-path, --fd, --reconnect, etc) and then manually parse them & pack their values together into a chardev object.

Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|