>Number:         33025
>Category:       kern
>Synopsis:       dmover makes radical assumptions about backends
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 07 17:15:00 +0000 2006
>Originator:     Gavan Fantom
>Release:        N/A
>Organization:
>Environment:
>Description:
There is no way to specify constraints on what a dmover backend can handle. A backend is expected to:

* be able to handle transfers of unlimited size
* be able to handle transfers at arbitrary unaligned addresses
* be able to handle transfers where inputs and outputs have *different* alignment
* be able to handle transfers with "unaligned" size
* be able to handle scatter/gather I/O

It is not uncommon for hardware using DMA to require that DMA transfer be aligned to a word, or some other power of two. It is also not uncommon for the size of a transfer to be similarly constrained.

Tricks involving separate handling of "heads" and "tails" to deal with unaligned data can not be applied here because the alignment of the inputs and the alignment of the output can not be guaranteed to be the same.

Many backends would also benefit from being able to put an upper limit on the size of transfer they will have to handle.

Also, some backends are unable to directly deal with scatter/gather I/O, so much work to split a request up into manageable chunks. A better place to do this would be within dmover, as then the same code could be leveraged for multiple backends.
>How-To-Repeat:
Try to implement a dmover backend using hardware which has constraints.
>Fix:
The dmover_backend structure should contain extra fields which allow a backend to specify constraints. dmover would then ensure that those constraints are satisfied, or choose a different backend.