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~} <herbert@xxxxxxxxxxxxxxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
