[PATCH] dma-buf: Implement simple read/write vfs ops

Chris Wilson chris at chris-wilson.co.uk
Thu Sep 19 15:52:55 UTC 2019


Quoting Daniel Vetter (2019-09-19 16:28:41)
> On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson <chris at chris-wilson.co.uk> 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


More information about the dri-devel mailing list