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

[Peter Xu <peterx@redhat.com>]

On Tue, Sep 10, 2024 at 07:32:19PM -0300, Fabiano Rosas wrote:
> 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.

Not sure how much it helps.  It adds more work, add slightly more code to
maintain (then we will then need to maintain the shim layer, and that's
per-compressor), while I am not sure it'll be good enough either..  For
example, even if it compiles it can still run into constant failure when
with the real library / hardware underneath.

This not so bad to me yet: do you still remember or aware of the "joke" on
how people remove a feature in Linux?  One can introduce a bug that can
directly crash when some feature enabled, then after two years the
developer can say "see, this feature is not used by anyone, let's remove
it".

I think it's a joke (which might come from reality..) but it's kind of a
way that how we should treat these compressors as a start, IMHO.  AFAIU
many of these compressors start with PoC-type projects where it's used to
justify the hardware features.  The next step is in production use but that
requires software vendors to involve, IIUC.  I think that's what we're
waiting for, on company use it in more serious way that sign these features
off.

I don't think all such compressors will reach that point.  Meanwhile I
don't think we (as qemu migration maintainers) can maintain that code well,
if we don't get sponsored by people with hardwares to test.

I think it means it's not our job to maintain it at 100%, yet so far.  We
will still try our best, but that's always limited.  As we discussed
before, we always need to rely on vendors so far for most of them.

If after a few releases we found it's broken so bad, it may mean it
finished its job as PoC or whatever purpose it services.  It means we could
choose to move on, with no joking.

That's why I think it's not so urgent, and maybe we don't need extra effort
to make it harder for us to notice nobody is using it - we keep everything
we know productions are actively using seriously (like multifd, postcopy,
etc.).  Either some compressors become part of the serious use case, or we
move on.  I recently do find more that the only way to make QEMU keep
living well is to sometimes throw things away..

-- 
Peter Xu