On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Quoting Daniel Vetter (2019-09-19 16:28:41) > > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > It is expected that processes will pass dma-buf fd between drivers, and > > > only using the fd themselves for mmaping and synchronisation ioctls. > > > However, it may be convenient for an application to read/write into the > > > dma-buf, for instance a test case to check the internal > > > dma_buf->ops->kmap interface. There may also be a small advantage to > > > avoiding the mmap() for very simple/small operations. > > > > > > Note in particular, synchronisation with the device is left to the > > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly > > > inside the read/write, so that the user can avoid synchronisation if > > > they so choose. > > > > > > "It is easier to add synchronisation later, than it is to take it away." > > > > Hm for mmap I think the explicit sync makes sense (we might even want > > to do it in userspace). Not so sure it's a great idea for read/write > > ... I guess we'd need to see what people have/had in mind for the > > userspace for this to decide. > > There's an O_SYNC flag for open(2): > > O_SYNC Write operations on the file will complete according to the > requirements of synchronized I/O file integrity completion (by > contrast with the synchronized I/O data integrity completion > provided by O_DSYNC.) > > By the time write(2) (or similar) returns, the output data and > associated file metadata have been transferred to the underly‐ > ing hardware (i.e., as though each write(2) was followed by a > call to fsync(2)). > > That seems applicable here? Hm yeah, sounds like a neat idea to use O_SYNC to decide whether writes/reads flushes or not. It's a bit a stretch since !O_SYNC would also give you un-coherent reads (or could at least). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
