On Wed, 19 Jul 2023 at 00:54, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Tue, Jul 18, 2023 at 03:32:39PM -0700, Eric Biggers wrote: > > On Tue, Jul 18, 2023 at 02:58:27PM +0200, Ard Biesheuvel wrote: > > > This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5. > > > > > > "zlib-deflate" was introduced 6 years ago, but it does not have any > > > users. So let's remove the generic implementation and the test vectors, > > > but retain the "zlib-deflate" entry in the testmgr code to avoid > > > introducing warning messages on systems that implement zlib-deflate in > > > hardware. > > > > > > Note that RFC 1950 which forms the basis of this algorithm dates back to > > > 1996, and predates RFC 1951, on which the existing IPcomp is based and > > > which we have supported in the kernel since 2003. So it seems rather > > > unlikely that we will ever grow the need to support zlib-deflate. > > > > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > --- > > > crypto/deflate.c | 61 +++++----------- > > > crypto/testmgr.c | 8 +-- > > > crypto/testmgr.h | 75 -------------------- > > > 3 files changed, 18 insertions(+), 126 deletions(-) > > > > So if this is really unused, it's probably fair to remove it on that basis. > > However, it's not correct to claim that DEFLATE is obsoleted by zlib (the data > > format). zlib is just DEFLATE plus a checksum, as is gzip. > > > > Many users of zlib or gzip use an external checksum and therefore would be > > better served by DEFLATE, avoiding a redundant builtin checksum. Typically, > > people have chosen zlib or gzip simply because their compression library > > defaulted to it, they didn't understand the difference, and they overlooked that > > they're paying the price for a redundant builtin checksum. > > > > An example of someone doing it right is EROFS, which is working on adding > > DEFLATE support (not zlib or gzip!): > > https://lore.kernel.org/r/20230713001441.30462-1-hsiangkao@xxxxxxxxxxxxxxxxx > > > > Of course, they are using the library API instead of the clumsy crypto API. > > > > Ah, I misread this patch, sorry. It's actually removing support for zlib (the > data format) from the scomp API, leaving just DEFLATE. That's fine too; again, > it ultimately just depends on what is actually being used via the scomp API. > But similarly you can't really claim that zlib is obsoleted by DEFLATE just > because of the RFC dates. As I mentioned, many people do use zlib (the data > format), often just because it's the default of zlib (the library) and they > didn't know any better. For example, btrfs compression supports zlib. > I am not suggesting either is obsolete. I am merely pointing out that zlib-deflate is as old as plain deflate, and so we could have implemented both at the same time when IPcomp support was added, but we never bothered.
