Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm

[Fruhwirth Clemens <clemens@endorphin.org>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:

> I think the generic scatterwalk changes are more important and 
> fundamental (still to be fully reviewed).
> 
> I agree with Fruhwirth that the cipher code is starting to become
> ungainly.  I'm not sure these patches are heading in the right direction 
> from a design point of view, although we do need the functionality.  
> 
> Perhaps temporarily drop the multible block changes above until we get the
> generic scatterwalk code in and a cleaned up design to handle cipher mode
> offload.
> 
> Fruhwirth, do you have any cycles to work on implementing your ideas for 
> more cleanly reworking Michal's multiblock code?

The changes, I purposed, shouldn't be too hard to implement. I will
build a skeleton for Michael, but I can't test the code, as I don't own
a padlock system, further, I'm sorry to say but, my time is somehow
constrained.. I really gotta start to write my diploma thesis, I'm
delaying this for too long for crypto stuff now.

But before I put that into the my queue, I would like to see some kind
of decision on an async crypto framework. acrypto cames with hardware
support. So, are we heading for hardware support in cryptoapi, hardware
support in acrypto, acrypto instead of cryptoapi, OCF instead of
cryptoapi, or put everything into the kernel and export 3 interface? 

And how - when there is more than one interface - are these projects
going to reuse code?

-- 
Fruhwirth Clemens <clemens@endorphin.org>  http://clemens.endorphin.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]