[Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework
jcrouse at quicinc.com
Fri Aug 26 17:30:42 UTC 2011
On 08/26/2011 10:28 AM, Clark, Rob wrote:
> On Fri, Aug 26, 2011 at 4:06 AM, Hans Verkuil<hverkuil at xs4all.nl> wrote:
>> Frankly, I'm not sure about the read and write. I don't really see the use
>> case. The whole point of buffer sharing is to avoid copying buffers, and that's
>> exactly what read and write do.
> The main point (and maybe there is no point) for read/write is an
> alternative interface for sw access to buffer.. it isn't really
> intended for performant use cases, but rather for edge-cases. Like
> when we want to grab one frame of video and use sw to generate a
> Possibly mmap interface would be fine. But read/write seems
> attractive because you could do an easier job of hiding some weird
> formats. (Which I suppose you could still do w/ mmap and fault
> handling games.)
> I don't have any immediate plans for such use (mmap would suffice),
> but it did seem good to have all the normal file ops supported. If
> someone passed me a fd in userspace, I would expect to be able to
> read() and write(), and would be a bit surprised if that wasn't
> supported. So I guess principle-of-least-surpise applies here.
In that same line of thought you should implement lseek too. I wouldn't
find it odd to not have read/write available, but that might be shaded by
my prior DRM experience.
Personally, if I was to use a read/write interface I would want something
close to the PWRITE ioctl that the i915 DRM driver uses, but I agree that
in any event read/write will be a lesser used path, except possibly in
the case of SW rendering (and I _hope_ that is a lesser used path).
More information about the Linaro-mm-sig