On Thu, Sep 28, 2023 at 11:16:53AM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 27, 2023 at 06:19:09PM +0200, Andrea Bolognani wrote: > > Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> > > --- > > src/node_device/meson.build | 4 ---- > > src/node_device/virtnodedevd.service.in | 25 ------------------------- > > > 2 files changed, 29 deletions(-) > > delete mode 100644 src/node_device/virtnodedevd.service.in > > Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> > > Though I wonder if its worth just keeping an empty stub here, with > the section headings. It'd be a little confusing to see the stubs > present for some daemons but not others. We'd have to do the same for sockets then, on account of virtxend using an override for them. Maybe we could change the merge script so that contents before the start of the first section are simply ignored, and then have $ cat src/node_device/virtnodedevd.service.in # Merged into src/virtd.service.in $ cat src/node_device/virtnodedevd.socket.in # Merged into src/virtd*.socket.in for services that don't need any overrides, and $ cat src/libxl/virtxend.service.extra.in # Merged into src/virtd.service.in [Unit] Wants=virtlockd.socket After=virtlockd.socket ... $ cat src/libxl/virtxend.socket.extra.in # Merged into src/virtd*.socket.in [Unit] ConditionPathExists=/proc/xen/capabilities for services that do. It would mean introducing quite a number of additional files, but maybe the advantages in terms of discoverability make up for that downside? If we allow empty overrides, we might be even able to simplify the way the various services are defined in their meson.build files, by somehow deriving the path of the file instead of requiring it to be provided explicitly. That part could be tricky though. Overall I'm not opposed to the idea, but let's consider it for a follow-up instead of stalling this further, okay? -- Andrea Bolognani / Red Hat / Virtualization
