[Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework

[Jordan Crouse]

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
> thumbnail.
>
> 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).

Jordan