Hi On Wed, Oct 31, 2018 at 8:05 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
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@redhat.com> 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
ok
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.
We are trying to define a common specification for vhost-user backends. Where do we stop defining what --chardev should support?
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.
The backends most likely won't use qemu chardev (nor qapi), and be limited to unix socket.
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 :|