Re: [PATCH] migration/multifd: Fix build for qatzip

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> On Tue, Sep 10, 2024 at 06:35:50PM -0300, Fabiano Rosas wrote:
>> Peter Xu <peterx@redhat.com> writes:
>> 
>> > The qatzip series was based on an older commit, it applied cleanly even
>> > though it has conflicts.  Neither CI nor myself found the build will break
>> > as it's skipped by default when qatzip library was missing.
>> 
>> It took longer than I expected.
>
> What took longer?

For a change that breaks the build to be committed in one of these parts
of the code that are disabled by default. You might remember I told you
in one of our meetings that I was concerned about that.

>
>> 
>> Do you think it would work if we wrapped all calls to external functions
>> in a header and stubbed them out when there's no accelerator support?
>
> I didn't catch the major benefit v.s. multifd_register_ops().  Any further
> elaborations?

I'm trying to find a way of having more code compiled by default and
only a minimal amount of code put under the CONFIG_FOO options. So if
some multifd code depends on a library call, say deflateInit, we make
that a multifd_deflate_init and add a stub for when !ZLIB (just an
example). I'm not sure it's feasible though, I'm just bouncing the idea
off of you.