On Tue, Dec 07, 2021 at 04:20:29PM +1100, Herbert Xu wrote:

On Fri, Dec 03, 2021 at 12:49:26PM -0800, Dmitry Torokhov wrote:

quoted

I must be getting lost in terminology, and it feels to me that what is
discussed here is most likely of no interest to a lot of potential
users, especially ones that do compression/decompression. In majority of
cases they want to simply compress or decompress data, and they just
want to do it quickly and with minimal amount of memory consumed. They
do not particularly care if the task is being offloaded or executed on
the main CPU, either on separate thread or on the same thread, so the
discussion about scomp/acomp/etc is of no interest to them. From their
perspective they'd be totally fine with a wrapper that would do:

int decompress(...) {
	prepare_request()
	send_request()
	wait_for_request()
}

and from their perspective this would be a synchronous API they are
happy with.

You can certainly do that as a Crypto API user.  And we do have
some users who do exactly this (for example, testmgr does that
when testing async algorithms).  However, this can't be a part of
the API itself since many of our users execute in atomic contexts.

That is what I am confused about: why can't it be a part of API? Users
that are running in atomic contexts would not be able to use it, but we
have a lot of precedents for it. See for example spi_sync() vs
spi_async(). Callers have a choice as to which one to use, based on
their needs.

Thanks.

-- 
Dmitry