On 08/26/2011 10:28 AM, Clark, Rob wrote:
On Fri, Aug 26, 2011 at 4:06 AM, Hans Verkuilhverkuil@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