On Monday 19 December 2011, Semwal, Sumit wrote: > I didn't see a consensus on whether dma_buf should enforce some form > of serialization within the API - so atleast for v1 of dma-buf, I > propose to 'not' impose a restriction, and we can tackle it (add new > ops or enforce as design?) whenever we see the first need of it - will > that be ok? [I am bending towards the thought that it is a problem to > solve at a bigger platform than dma_buf.] The problem is generally understood for streaming mappings with a single device using it: if you have a long-running mapping, you have to use dma_sync_*. This obviously falls apart if you have multiple devices and no serialization between the accesses. If you don't want serialization, that implies that we cannot have use the dma_sync_* API on the buffer, which in turn implies that we cannot have streaming mappings. I think that's ok, but then you have to bring back the mmap API on the buffer if you want to allow any driver to provide an mmap function for a shared buffer. Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>