Subject: Re: [RFC] Interface to hardware-assisted data movers
To: Cliff Neighbors <cliff@allegronetworks.com>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 06/19/2002 18:01:26
On Wed, Jun 19, 2002 at 05:41:08PM -0700, Jason R Thorpe wrote:

 >  > These can be useful when moving data through device fifo registers,
 >  > or for block fill & zero.  Perhaps the API can define flags for set up 
 >  > addr hold mode (or none).
 > 
 > Hm, can you give me a better idea of what you mean by "hold" in this
 > case?  I.e. what are the exact semantics, here?

Hm, to follow-up... Matt Thomas mentioned to me what you might mean
by this... like "source address doesn't auto-increment" or "dest address
doesn't auto-increment", right?

If that is the case, then this could (and, I think, should :-) be handled
by using a different "function", i.e. instead of "copy-block", you might
have "stream32-out" to slurp from a held source 32-bits at a time and
a "stream32-in" to slurp from a memory region into a held destination
32-bits at a time.  Since dmover uses strings to describe the functions,
you can add whatever your back-ends might provide, and the API handles it
transparently.

BTW, the reason I want it as a separate function is so that the name
of the function is the only thing a back-end has to do to advertise its
capabilities.  E.g. if a device can do a 6-way XOR operation, then it
would provide an algdesc named "xor-6".  I want to avoid having to introduce
flags, because flags don't always scale well, esp. if you're trying to
describe complex combinations of operations.

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