Hi!
On 08/22/2015 01:06 AM, Tiago Vignatti wrote:
> Hi back!
>
> On 08/20/2015 03:48 AM, Thomas Hellstrom wrote:
>> Hi, Tiago!
>
> Something that the Chrome OS folks told me today is whether we could
> change the sync API to use a syscall for that instead. Reason for that
> is to eventually fit this in nicely in their sandbox architecture
> requirements, so yet another ioctl wouldn't need to be white-listed
> for the unpriviledged process.
>
> How does that change the game, for example regarding the details we
> been talking here about make the sync mandatory? Can we reuse, say
> msync(2) for that for example?
To me, the mechanism itself is the most important, but I think it should
be much easier to have an IOCTL accepted since the functionality is
limited to dma-bufs.
In any case, Ideally I'd want the struct dma_buf_sync look something like
enum dma_buf_sync_flags {
DMA_BUF_SYNC_READ = (1 << 0),
DMA_BUF_SYNC_WRITE = (2 << 0),
DMA_BUF_SYNC_RW = (3 << 0),
DMA_BUF_SYNC_START = (0 << 2),
DMA_BUF_SYNC_END = (1 << 2),
DMA_BUF_SYNC_VALID_FLAGS_MASK = DMA_BUF_SYNC_RW |
DMA_BUF_SYNC_END
};
/* begin/end dma-buf functions used for userspace mmap. */
struct dma_buf_sync {
enum dma_buf_sync_flags flags;
__u64 x;
__u64 width;
/* 2D Sync parameters */
__u64 stride;
__u64 y;
__u64 height;
}
So again, why use a 2D sync in the first place when it's probably possible to batch 1D syncs in the driver?
It all boils down to the number of syscalls required, and also the fact that it's probably not trivial to batch sync calls in the read-write case. One can, again, argue that there might be 3D cases or other obscure sync cases,
but in that case, let's implement them in the future if the overhead becomes unbearable. If the sync mechanism gets established as
mandatory, the problem will solve itself. And at least now we cover the most common case and we don't need to add a new multiplexing
mechanism in the sync IOCTL since we already have one in the IOCTL mechanism. We can simply add a new sync IOCTL for new obscure sync cases if desired.
Also, in fact I believe this also gives us a hint whether to use sycalls or IOCTLs: If we want to maintain the possibility to extend the synchronization mechanism, I strongly believe we need to use an IOCTL.
/Thomas
>
> Best Regards,
>
> Tiago
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
