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
