On Sat, Mar 16, 2024 at 12:40:33PM +0800, Herbert Xu wrote: > On Fri, Mar 15, 2024 at 05:26:21PM -0700, Chris Goldsworthy wrote: > > Hi There, > > > > If a compression driver were submitted upstream that used HW LZO decompression > > and SW LZO compression, could it be accepted? It would be geared towards > > decompressing boot images on IOT-type targets with exteremely limited secondary > > storage. > > Who is the intended user in the kernel? In general, Crypto API > drivers will be accepted if there is at least one in-kernel user. Hi Herbert, Digging this up again after we've settled on more design choices internally. We're planning for this block to use LZ4, and in the kernel we'd like to use it with zswap. For our implementation, we intend on capping the size of our history window to 4 KB, in order to reduce the area of the block, which would mean that we're only guaranteed to be able to compress 4 KB buffers (the LZ4 spec uses a 64 KB history window). IAA faced a similar limitation [1], but I just want to make sure our situations are identical w.r.t. being able to get out driver accepted. SW will be able to decompress compressed content we produce, we just can't compress buffers of arbitrary sizes (users would need to break them into individual 4 KB requests). Thanks, Chris. [1] https://lore.kernel.org/linux-crypto/ZLsvdS6NbaetDFe1@xxxxxxxxxxxxxxxxxxx/
