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: > > > > 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