On Tue, Oct 03, 2017 at 06:07:53PM +0200, Paolo Bonzini wrote: > On 03/10/2017 17:59, Michal Privoznik wrote: > > Ah, this breaks my design. I guess > > > > <disk> > > <pr> > > <source type='unix' path='/path/to/qemu-pr-helper' mode='server'/> > > </pr> > > </disk> > > > > is pure madness, isn't it? > > Yes, but OTOH if libvirtd starts the daemon, nobody cares about the > source type, so perhaps > > <pr driver='helper' mode='shared'> > <source ... /> > </pr> > > (mandatory source) vs. > > <pr driver='helper' mode='private'> > <path>/path/to/qemu-pr-helper</path> > </pr> > > (optional path, default from global configuration) vs. > > <pr driver='passthrough'/> > > (no helper)? I tend to think we should not expose the concept of a 'helper' at all in the XML. The fact that QEMU has a separate binary to do this is really an internal implementation detail due to the need for privilege separation/ elevation. Libvirt should just do the right thing running the helper with a suitable configuration when needed, just like we run the TAP device helper when needed. IOW, just be as simple as an attribute "reservations=on|off" and we'll decide the UNIX socket path, daemon forking, etc ourselves 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
