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.
