> > +int qemuDomainAttachDeviceLiveAndConfig(virConnectPtr conn, >> + virDomainObjPtr vm, >> + virQEMUDriverPtr driver, >> + const char *xml, >> + unsigned int flags); >> + >> +int qemuDomainDetachDeviceLiveAndConfig(virQEMUDriverPtr driver, >> + virDomainObjPtr vm, >> + const char *xml, >> + unsigned int flags); >> + >> #endif /* __QEMU_DRIVER_H__ */ >> > > This should not be exposed in qemu_driver.h, instead the functions > should be moved to qemu_domain.h if possible, but they now fit there. > > If that's not possible, we need to do similar thing as we now have with > qemu_processpriv.h, so this could be called qemu_domainpriv.h I guess
Did you mean qemu_driverpriv.h? As you predicted, it's not easily done. qemuDomainAttachDeviceLiveAndConfig() indirectly uses a few functions from qemu_hotplug. It would be pointless to move them all to qemu_domain.h, because then we would have to drag the whole qemu_hotplug.[hc] along. What can be done is moving these to qemu_hotplug.h: - qemuDomainAttachDeviceLive() - qemuDomainDetachDeviceLive(), and these to qemu_domain.h: - qemuDomainAttachDeviceConfig() - qemuDomainDetachDeviceConfig() - qemuDomainChrPreInsert() - qemuDomainChrInsertPreAlloced() - qemuDomainChrInsertPreAllocCleanup() - qemuDomainChrInsert() - qemuDomainChrRemove(). But then where should qemuDomainAttachDeviceLiveAndConfig() and qemuDomainDetachDeviceLiveAndConfig() be? In that qemu_domainpriv/qemu_driverpriv.h? And should their definitions still be in qemu_driver.c, or in a brand new .c file? Btw qemuDomainUpdateDeviceFlags() is still unsplit and it deserves the same treatment as the other two *DeviceFlags functions. It will be done in v3. Thank you again for such thorough reviews! I really appreciate it. Tomasz
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list