[Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
Daniel Vetter
daniel.vetter at ffwll.ch
Thu Sep 19 16:18:07 UTC 2019
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> 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?
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
More information about the dri-devel
mailing list