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?
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
