On Mon, Feb 23, 2009 at 10:46:43AM -0800, Loc Ho wrote:
>
> I'd like to see a name field. It's better to have user-space
> pass through a string for the type instead of an ID.
>
> The reason you want user-space to pass that through is so that
> you can locate the crypto_type object and then call crypto_alloc_tfm
> on it..
>
> [Loc Ho]
> The name field would not be known here. It will be at the cryptodev layer as
> it is the layer that create the tfm. In the above two functions, the
> parameter tfm has already been created.
Well it would be known if you added a name field to uspace_session
below :)
> Also the other two functions should take a void * instead of
> crypto_tfm * since crypto_alloc_tfm now returns that.
>
> [Loc Ho]
> The function ctxsize, init, exit, and show already existed. For cryptodev, I
> added only uspace_setparam and uspace_op. We will change their first
> parameter to void *.
Right I only meant the new functions. These existing functions
will retain the crypto_tfm.
> > struct uspace_session {
> > __u8 alg_name[64];
> > __u32 front_type; /* I don't believe we need this - leave for now */
>
> So instead of front_type I'd like to see front_type_name.
>
> [Loc Ho]
> Okay... Maybe you see some value having a front_type_name. But as of right
> now, I only see the need for alg_name, type, and mask.
It makes a difference because for different types we need to call
different construnction/alloc functions. In fact, I think we should
add a construction function to the type object too.
> [Loc Ho]
> Okay... This would requires the caller to call the recvmsg and make use of
> standard async/sync socket interface. For async interface, caller will have
> to call the recvmsg. A sendmsg will always returns success unless HW ring is
> full. For sync interface, the function will block until the operation
> completed. If we switch to this interface, are you going to stick with this
> interface and apply this - at least until there is a better reason to change?
> Even if there is a good reason to change, I would like to see a version
> available in the crypto tree if not Linux kernel release tree. We will also
> look at splice as well if time permit.
Well once an interface hits Linus's tree that's it, game over :)
So that's we're having all these discussions in order to make sure
that we don't have any regrets.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
