Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

[Herbert Xu]

On Wed, Aug 09, 2017 at 11:40:12AM +0200, Corentin Labbe wrote:
>
> I really didnt see how to do that since cra_type is const.
> Anyway, I think it cannot be possible since we could have two different engine with two different prepare_request().
> 
> I will really appreciate any advice on what you want exactly.

The issue is that we have these handlers such as prepare_request
that gives us a level of indirection into the driver.  However,
on top of those we're adding another level of indirection based
on the type of request.

I'd like to see these two combined into just a single function
pointer.

My idea of using cra_type is indeed broken as these functions
ultimately live in the driver and not crypto API.

So how about something like this:

struct crypto_engine_op {
	int (*prepare_request)(struct crypto_engine *engine,
			       struct crypto_async_request *req);
	int (*unprepare_request)(struct crypto_engine *engine,
				 struct crypto_async_request *req);
	int (*do_one_request)(struct crypto_engine *engine,
			      struct crypto_async_request *req);
};

struct crypto_engine_reqctx {
	struct crypto_engine_op *op;
};	

struct crypto_engine {
	struct crypto_engine_op aead;
	struct crypto_engine_op hash;
	struct crypto_engine_op cipher;

	...
};

Then in the request_to_engine functions you would store the right
op pointer inside the request context area.  Obviously the users
of crypto_engine would need to allocate space for the struct
crypto_engine_reqctx in their reqctx structure.

The only wart with this scheme is that the drivers end up seeing
struct crypto_async_request and will need to convert that to the
respective request types but I couldn't really find a better way.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt