Hi
On Tue, Oct 16, 2018 at 4:14 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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" } } }'
instead of:
--socket-path=/tmp/foo.sock
I don't really get what that will help with, for the vhost-user backend case...
>
> 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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
