Anthony Liguori wrote: >> >> - DMA into mmio regions; this requires bouncing > > The map() API I proposed above should do bouncing to MMIO regions. To > deal with unbounded allocation, you can simply fail when the mapping > allocation has reached some high limit. Calling code needs to cope > with the fact that map'ing may succeed or fail.
There are N users of this code, all of which would need to cope with the failure. Or there could be one user (dma.c) which handles the failure and the bouncing. dma.c _is_ a map/unmap api, except it doesn't expose the mapped data, which allows it to control scheduling as well as be easier to use. > >> - DMA with an associated transform (xor, byteswap); also requires >> bouncing > > At this layer of the API, this is unnecessary. At the PCI layer, you > would need to handle this and I'd suggest taking the same approach as > above. I agree to _map()/_unmap(), but it's not a solution by itself. > >> In turn, bouncing requires splitting large requests to avoid >> unbounded memory allocation. >> >> While I think _map/_unmap is an improvement over can_dma(), this API >> can't handle bounded bouncing, and so a separate layer (dma.c) is >> still necessary. > > I think it can handled bounded bouncing fine. It's a matter of > ensuring the bounce buffer max is sufficiently large and ensuring that > any client code can cope with map failures. In fact, there probably > needs to be a notifiers API that is invoked whenever an unmap() > happens so that if an asynchronous request is waiting because of a map > failure, it can be notified as to when it should try again. Right, but who would it notify? We need some place that can deal with this, and it isn't _map()/_unmap(), and it isn't ide.c or scsi.c. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
