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

[Daniel P . Berrangé]

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é <address@hidden> 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 :|