On Mon, Jul 29, 2019 at 07:14:36PM +0000, Jim Fehlig wrote: > On 7/29/19 8:18 AM, Andrea Bolognani wrote: > > On Mon, 2019-07-29 at 13:17 +0100, Daniel P. Berrangé wrote: > >> On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote: > >>> Again IIUC there's nothing really stopping us from generating > >>> virtqemud*.service from libvirtd*.service.in, or at least from > >>> a common virtd*.service.in, since eg. virtqemud.service.in and > >>> virtlxcd.service.in are basically identical - it's just that you > >>> haven't unified the generation rules yet. > >> > >> I'm was not anticipating sharing the service.in file, as many of > >> the parameters will be driver specific. > > > > It doesn't look to me like there's much more that's driver-specific > > in the .service files than there is in the .socket files, and we're > > generating the latter from a single template. > > I have a downstream patch that adds > > After=xencommons.service > Conflicts=xendomains.service > > to libvirtd.service.in. IMO the patch needs to be improved before pushing > upstream, e.g. conditionally adding those lines at build time when the xen > driver is selected. With driver-specific service files we can trivially add > those to virtxend.service. Sure, go ahead & send that for libvirtd.service.in Meanwhile, I'll add them to virtxend.sevice in my patch series right now. 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
