Hi
On Tue, Oct 16, 2018 at 4:14 PM Daniel P. Berrangé <berrange(a)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" } } }'
instead of:
--socket-path=/tmp/foo.sock
I don't really get what that will help with, for the vhost-user backend case...