Re: [libvirt] [PATCH] test_driver: consider flags in testDomainSetMemoryFlags

On 7/11/19 9:15 AM, Ilias Stamatis wrote: Separate patches in a series is fine. My eventual goal is to git rid of multiple driver callbacks, and have JUST .drvDomainSetMemoryFlags() for drivers to implement. But for that to work, we have to teach the remote driver to call the OLD RPC function for every scenario where the old function is a trivial wrapper around the new (in some cases, that's when flags==0, in others, when flags==VIR_DOMAIN_AFFECT_CURRENT), in case the remote driver is talking to an older libvirt that did not yet have the implementation of the new callback function. That is, if libvirt 5.7 as client calls virDomainSetMaxMemory(), that will call into the remote driver as .drvDomainSetMemoryFlags(, default_flags), then the remote driver will see the default flags and call the RPC for DOMAIN_SET_MAX_MEMORY, in case on the remote side is running 5.5 or older and has the older .drvDomainSetMaxMemory() for a driver that did not yet have .drvDomainSetMemoryFlags() support. We don't want to fail the call just because the new callback was missing in the older server. But to do that, we have to audit ALL of the drivers with paired APIs and ensure that, at least in new libvirt, the pairings all use the same default_flags (for knowing when to fall back to the old API), and that for old libvirt, that falling back to the old API is not going to subtly change semantics for whehter a libvirt 5.5 or libvirt 5.7 client made the request. That's why it is a bigger issue, and needs some careful thought. I started on the topic, but it is now lower-priority for me than getting incremental backup into 5.6, so it might not happen until 5.7. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org