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 <kra...@redhat.com> 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
