On Wed, Sep 04, 2013 at 12:24:27PM +0200, Martin Peres wrote:ACK, thanks Daniel.Hi Christopher,Size is an invariant part of a dma-buf. Everything else wrt metadata isn't
Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit :
Each dma-buf has an associated size and it's reasonable for userspaceShouldn't it be "supported" instead of "support"?
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.
v2: Added Daniel's sugeested documentation, with minor fixups
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@xxxxxxxxxxxxx>
Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
Tested-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
---
Documentation/dma-buf-sharing.txt | 12 ++++++++++++
drivers/base/dma-buf.c | 28 ++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 0b23261..849e982 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
interesting ways depending upong the exporter (if userspace starts depending
upon this implicit synchronization).
+Other Interfaces Exposed to Userspace on the dma-buf FD
+------------------------------------------------------
+
+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only
+ with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow
+ the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
+ llseek operation will report -EINVAL.
+
+ If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
Anyway, I'm just curious, in which case is it important to know the size?
Do we already have a way to get the dimensions (x, y and stripe)?
tracked in the kernel, so doesn't make much sense to expose it ;-)
-Daniel