[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZG6tun6TOYKr1nxK@gondor.apana.org.au>
Date: Thu, 25 May 2023 08:37:14 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Tom Zanussi <tom.zanussi@...ux.intel.com>
Cc: davem@...emloft.net, fenghua.yu@...el.com, vkoul@...nel.org,
dave.jiang@...el.com, tony.luck@...el.com,
wajdi.k.feghali@...el.com, james.guilford@...el.com,
kanchana.p.sridhar@...el.com, giovanni.cabiddu@...el.com,
linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
dmaengine@...r.kernel.org
Subject: Re: [PATCH v5 13/15] crypto: iaa - Add support for default IAA
'canned' compression mode
On Wed, May 24, 2023 at 10:58:54AM -0500, Tom Zanussi wrote:
>
> Yes, I think you're right. The reason we did it this way was that
> we're expecting to add more modes, such as 'dynamic' and/or 'canned-
> dynamic' etc.
>
> But I don't see a reason we couldn't just register them all and have
> the user choose using the algorithm names, especially if that's the way
> crypto users expect things to work.
Are these modes compatible with the deflate algorithm, that is,
can the generic deflate uncompress the output of these modes and
vice versa, can these modes uncompress the output of the generic
algorithm?
If they're all compatible, then you should just use the "deflate"
algorithm name and use different driver names to differentiate them.
But if they're not compatible then the modes should have distinct
algorithm names.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists