On Thu, Jun 20, 2002 at 08:59:21AM +0900, itojun@iijlab.net wrote:

 > 	it looks to me the API could be used for block ciphers (and crypto
 > 	accelerators) too.  so we may be able to provide:
 > 	- fill region by random number (easy)

I think for hardware devices that can provide random numbers, what we
really want is for them to feed into the kernel's entropy pool.  In most
cases where we want a block of random data (e.g. IV's), the amount of
data we want isn't going to justify the overhead of using dmover.  (One
of the biggest advantages of dmover is that it's asynchronous, so you can
do other work while you're waiting for your RAID parity to be computed.)

Did you have something else in mind for a "rand-block" dmover function?

 > 	- block ciphers, like DES/AES/whatever
 > 	one issue is, with the latter, how to pass keys from clients to dmover,
 > 	and how to manage keys configured into the crypto cards within dmover. 

Actually, I have a separate framework for data transformations like ciphers
(or MPEG encode/decode, etc.).  I originally wanted to have them handled by
the same framework, but there were some interface issues that were too
difficult to solve:

	* The xform interface started to get ugly when I attempted to
	  handle the multiple-inputs and immediate-input stuff that
	  dmover needs (e.g. 6-way XOR, etc.).

	* The types of operations you perform with xform are different
	  than data movement, e.g. "compute hash", "encode/encrypt",
	  "decode/decrypt", "sign data blob", "verify signature".

	* Xform has a different buffer management strategy (mostly because
	  of some of the intended uses of xform), and only supports one
	  input stream.

The nice thing is that the middle layers of both dmover and xform are
VERY small, and they are definitely less complicted as a result of
splitting them apart.

I will post more about the xform facility soon (I haven't written any
documentation for it yet :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>