On Fri, Oct 12, 2018 at 00:10:02 -0500, Eric Blake wrote: > The following is the latest version of my API proposal for > incremental backups. > > I have even more work-in-progress patches on top of these: > https://repo.or.cz/libvirt/ericb.git > which I am slowly improving to be more in line with my thread > on the overview of the API usage: > https://www.redhat.com/archives/libvir-list/2018-October/msg00217.html > > But I am fairly satisfied that the API as presented is sufficient for > everything I have still been implementing in the qemu driver, and > that even when qemu is slightly tweaked (such as dropping the x- > prefix on various commands, or maybe adding a new command to make > it easier to compute the estimated size of the union of several > bitmaps), those changes will be limited to the src/qemu directory > rather than affecting the API. > > Since I will be demonstrating the use of this API at the KVM Forum, > I would really like a decision on whether we can commit the API > into libvirt now, even if we have to wait for the qemu implementation No we can't. We did it once in the past and although I don't remember the exact details I remember it turned out to be a bad idea. Also pushing an API with no implementation doesn't really make sense since the API is unusable until it is implemented in some hypervisor driver. > of the API until qemu stabilizes its interfaces (also, having the > libvirt API in place gives qemu an incentive to drop the x- prefix > sooner rather than later). The presence of public API in libvirt gives no clue to QEMU engineers that their API provides everything needed and x- prefix should be dropped. Only working patches implementing the libvirt APIs for QEMU can provide such feedback to QEMU developers. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
