On Fri, Aug 26, 2011 at 12:30 PM, Jordan Crouse <jcrouse@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@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.

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@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig