Exporting modules which do not wish to provide any specific name may use the
helper define 'dma_buf_export()', with the same arguments as above, but
- without the last argument; a __FILE__ pre-processor directive will be
+ without the last argument; a KBUILD_MODNAME pre-processor directive will be
inserted in place of 'exp_name' instead.
2. Userspace gets a handle to pass around to potential buffer-users
and then allow further {map,unmap}_dma_buf operations from any buffer-user
from the migrated backing-storage.
- If the exporter cannot fulfil the backing-storage constraints of the new
+ If the exporter cannot fulfill the backing-storage constraints of the new
buffer-user device as requested, dma_buf_attach() would return an error to
denote non-compatibility of the new buffer-sharing request with the current
buffer.
No special interfaces, userspace simply calls mmap on the dma-buf fd.
-2. Supporting existing mmap interfaces in exporters
+2. Supporting existing mmap interfaces in importers
Similar to the motivation for kernel cpu access it is again important that
the userspace code of a given importing subsystem can use the same interfaces
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
+ cases. Userspace can use this to detect support for discovering the dma-buf
+ size using llseek.
+
Miscellaneous notes
-------------------