dmabuf have just accept one ioctl for cache management but I think that some exporter may need also need custom iotcl. For example I'm working since a while on a way to secure buffer (SMAF) [1] which is a central allocator + 2 ioctl for set/get secure status of the buffer. This not depend on one device but on the buffer itself and so need to be handled by the exporter. To implement this I see 3 solutions: - create an allocator with ioctl like SMAF but until now I don't get lot of feedback on this so I guess it is a wrong way. - add ioctl and ops in dmabuf but if we do that for buffer securing how many ioctls will have to be handled by dmabuf for other feature? - let exporters define their own ioctl (like done in ION), it could allow to create per features helpers for the exporters. What is the best option when you have to do something relative to the buffer and to the device ? Regards, Benjamin [1] https://lwn.net/Articles/676270/ 2016-03-09 10:18 GMT+01:00 Christian König <deathsimple@xxxxxxxxxxx>: > Am 09.03.2016 um 10:03 schrieb Daniel Vetter: >> >> On Wed, Mar 9, 2016 at 9:54 AM, Benjamin Gaignard >> <benjamin.gaignard@xxxxxxxxxx> wrote: >>> >>> In addition of the already existing operations allow exporter >>> to use it own custom ioctls. >>> >>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxx> >> >> First reaction: No way ever! More seriously, please start by >> explaining why you need this. > > > I was about to complain as well. Device specific IOCTLs should probably > better defined as operation on the device which takes the DMA-Buf file > descriptor as a parameter. > > If you really need this (which I doubt) then please define a range of IOCTL > numbers for which it should apply. > > Regards, > Christian. > > >> -Daniel >> >>> --- >>> drivers/dma-buf/dma-buf.c | 3 +++ >>> include/linux/dma-buf.h | 5 +++++ >>> 2 files changed, 8 insertions(+) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 9810d1d..6abd129 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -291,6 +291,9 @@ static long dma_buf_ioctl(struct file *file, >>> >>> return 0; >>> default: >>> + if (dmabuf->ops->ioctl) >>> + return dmabuf->ops->ioctl(dmabuf, cmd, arg); >>> + >>> return -ENOTTY; >>> } >>> } >>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h >>> index 532108e..b6f9837 100644 >>> --- a/include/linux/dma-buf.h >>> +++ b/include/linux/dma-buf.h >>> @@ -70,6 +70,9 @@ struct dma_buf_attachment; >>> * @vmap: [optional] creates a virtual mapping for the buffer into >>> kernel >>> * address space. Same restrictions as for vmap and friends >>> apply. >>> * @vunmap: [optional] unmaps a vmap from the buffer >>> + * @ioctl: [optional] ioctls supported by the exporter. >>> + * It is up to the exporter to do the proper copy_{from/to}_user >>> + * calls. Should return -EINVAL in case of error. >>> */ >>> struct dma_buf_ops { >>> int (*attach)(struct dma_buf *, struct device *, >>> @@ -104,6 +107,8 @@ struct dma_buf_ops { >>> >>> void *(*vmap)(struct dma_buf *); >>> void (*vunmap)(struct dma_buf *, void *vaddr); >>> + >>> + int (*ioctl)(struct dma_buf *, unsigned int cmd, unsigned long >>> arg); >>> }; >>> >>> /** >>> -- >>> 1.9.1 >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> > -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
