On 3/16/06, Kumar Gala [off-list ref] wrote:

It would seem that when a client registers (or shortly there after
when they call dma_async_client_chan_request()) they would expect to
get the number of channels they need by some given time period.

For example, lets say a client registers but no dma device exists.
They will never get called to be aware of this condition.

I would think most clients would either spin until they have all the
channels they need or fall back to a non-async mechanism.

Clients *are* expected to fall back to non-async if they are not given
channels. The reason it was implemented with callbacks for
added/removed was that the client may be initializing before the
channels are enumerated. For example, the net subsystem will ask for
channels and not get them for a while, until the ioatdma PCI device is
found and its driver loads. In this scenario, we'd like the net
subsystem to be given these channels, instead of them going unused.

Also, what do you think about adding an operation type (MEMCPY, XOR,
CRYPTO_AES, etc).  We can than validate if the operation type
expected is supported by the devices that exist.

No objections, but this speculative support doesn't need to be in our
initial patchset.

Shouldn't we also have a dma_async_client_chan_free()?

Well we could just define it to be chan_request(0) but it doesn't seem
to be needed. Also, the allocation mechanism we have for channels is
different from alloc/free's semantics, so it may be best to not muddy
the water in this area.

Regards -- Andy