[External] Re: [PATCH v2 1/4] API: introduce memory failure

Michal Privoznik mprivozn at redhat.com
Wed Oct 14 09:18:58 UTC 2020

On 10/14/20 4:44 AM, zhenwei pi wrote:
> I described it in '[PATCH v2 4/4] virsh: implement memory failure event'
> Notice:
> The full patch set includes 4 patches:
> virsh: implement memory failure event         (current patch)
> qemu: monitor: handle memory failure event
> qemu: process: implement domainMemoryFailure
> API: introduce memory failure
> To avoid build/test errors, the 4 patches should be merged/removed
> together.
> Suggested by Peter, separate a 'all in one' patch into 4 patches 
> (described in cover letter '[PATCH v2 0/4] support memory failure').
> I forked a repo and pushed the 4 
> patches(https://gitlab.com/pacepi/libvirt/-/tree/memory-failure-v2), CI 
> worked fine.

To add to Peter's reply: the reason we require each patch to build on 
its own is backport. You are not doing it necessarily in your series, 
but if for instance you'd move some code then:

1) it's a standalone change that should be in a separate patch
2) if a distribution wants to backport the patch (e.g. because it is a 
prerequisite for some other patch), then the code base should build 
without having to backport irrelevant patches.

And to some extent your patches can be viewed as backportable. I can 
imagine that somebody writes the code for other driver (say libxl) and a 
distro might want to backport it. It will need to backport this patch 
which adds the RPC and client facing APIs. But at the current state it 
can't do so because it won't compile.

Looking forward to v3.


More information about the libvir-list mailing list