[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.
Michal
More information about the libvir-list
mailing list