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

[Sumit Semwal]

On 26 August 2011 23:39, Clark, Rob <rob at ti.com> wrote:

> On Fri, Aug 26, 2011 at 12:30 PM, Jordan Crouse <jcrouse at quicinc.com>
> wrote:
> > 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.
>
> yeah, I assume lseek (if we have read/write).. well default_llseek
> would be enough for any scenario I could think of, but I guess we
> might as well let the exporting driver provide default_llseek if that
> is what it wants
>
> re: DRM.. well, I assume that is because you don't have a fd for GEM
> objects..
>
> anyways, "normal" fileops aren't a must-have.. the use-cases of sw
> access that I could think of would probably prefer mmap.  There
> shouldn't be any issue to add them later if someone came up for a good
> reason to have 'em.
>
Ok - so to consolidate feedback: I would remove off read-write() calls [from
both dma-buf-ops and fileops], leave mmap() in. If during the course of
development, like Rob said, should anyone need a reason for them to be in,
we can add them back.

BR,
~Sumit.

>
> BR,
> -R
>
> > 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
> >
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>



-- 

Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs*
***

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
Twitter<http://twitter.com/#!/linaroorg>
 | Blog <http://www.linaro.org/linaro-blog/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20110829/0e9a41f1/attachment.html>