On Mon, Nov 25, 2019 at 05:06:31PM +0100, Michal Privoznik wrote: > On 11/24/19 10:33 PM, Julio Faracco wrote: > > Thanks for your explanation, Peter! > > > > I will focus on LXC side then... > > > > You may still implement the API for other drivers too. The way we addressed > this problem in the past is to create new API and have the old one call the > new one. That's why we have "virSomething WithFlags()" APIs - because simply > when introducing virSomething() API we did not think of adding flags. But if > you then look how virSomething is implemented at driver level (say qemu > driver) then you will see virSomething() is a very thin wrapper that calls > virSomethingWithFlags(..., 0);. > > > For instance virDomainCreate() and virDomainCreateWithFlags() and > qemuDomainCreate() and qemuDomainCreateWithFlags(). > > So you will need to add a new API and then have the old call the new one > with sensible @source. Since the sensible value can differ among drivers I > guess we can have VIR_DOMAIN_HOSTNAME_SRC_DEFAULT which would mean > "hypervisor driver default as in the most sensible source chosen > automatically by driver". This API already has flags, so the alternative to adding a "source" parameter is to reuse the flags parameter to express the desired data source. This is what we do the virDomainReboot/Shutdown methods. The separate source parameter is the approach for virDomainGetInterfaces. While it is certainly nicer to have a separate source, I think reusing the flags parameter is acceptable given the API design we have. 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
