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 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..

Ok, that's all fair. I agree we can continue with that policy. Thanks
for sharing your thoughts.