Re: [PATCH v1 0/3] zram: introduce crypto-backend api

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (24/11/21 12:11), Alexey Romanov wrote:
> > Sorry, no, we are not adding this for a hypothetical scenario.
> > 
> > > For example, he can use some driver with hardware compression support.
> > 
> > Such as?  Pretty much all H/W compression modules (I'm aware of)
> > that people use with zram are out-of-tree.
> 
> At least we have this:
> 
> drivers/crypto/nx/nx-common-powernv.c:1043:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/nx/nx-common-pseries.c:1020:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:377:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:392:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> 
> Anyway, if we want to completely abandon Crypto API

It's more complicated than that.

> these modules still need to be supported in zram.

We support what we have always claimed we supported, namely
what is listed in drivers/block/zram/Kconfig.  That's how one
enables a particular algorithm in zram - during zram configuration.
If those algos are not in zram's Kconfig after so many years,
then it's most likely because people don't use them with zram.
If we ever need backends for those H/W algos, then I really would
prefer a patch from folks that have a corresponding hardware to
run and test it on.  The thing is, zram, in its current form and
shape, imposes strict requirements on comp implementation.

So we should not add algos just because they are there (especially
H/W algos) that's how we added 842, lz4hc many years ago and now
have to carry them around.  We are not doing that again.