Re: [Qemu-devel] [PATCH v4 00/29] vhost-user for input & GPU

[Gerd Hoffmann]

On Tue, Sep 11, 2018 at 01:16:22PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Sep 11, 2018 at 12:59 PM Gerd Hoffmann <address@hidden> wrote:
> >
> > > > >  $ ./vhost-user-gpu --virgl -s vgpu.sock &
> > > > >  $ qemu...
> > > > >    -chardev socket,id=chr,path=vgpu.sock
> > > > >    -object vhost-user-backend,id=vug,chardev=chr
> > > > >    -device vhost-user-vga,vhost-user=vug
> > > >
> > > > That's a bit incovenient for qemu command line users. But who runs
> > > > qemu this way but some developers? (others have higher-level scripts /
> > > > tools or libvirt)
> >
> > In practice this will *allways* run over a unix socket, right?
> > So I'm wondering whenever it makes sense to take the chardev
> > indirection here ...
> 
> The management layer can set things up and pass fd around, avoiding
> socket paths etc.

But that fd will be a socket too ...

> > > - optionally? take a "--pid=PATH" argument, to write out the process PID
> >
> > Do we need that?  When libvirt forks off the process it knows the PID
> > without pidfile, right?
> 
> Yes I am not sure it is strictly necessary (that's why I put
> optionally). The helper could fork itself, for various reasons.

Ok, good point.  But then I'd make this mandatory, and maybe name it
--pidfile.  Shouldn't a big burden as you probably have code for that in
the vhost-user helper lib

> Unknown capabilities would be ignored.

Ok, so when libvirt ignores unknown stuff anyway a list of keywords is
good enough I guess.  And for humans having --help is more useful.

I'd include the protocol into the names, for robustness reasons, i.e.
use "input-grab" or "gpu-vulkan".

cheers,
  Gerd