On Thu, Jan 24, 2019 at 02:43:02PM +0100, Jaroslav Kysela wrote:
If I look to the dma_buf_fd() implementation:
fd = get_unused_fd_flags(flags); fd_install(fd, dmabuf->file);
.. what if we just add one new ioctl to the ALSA's PCM API which will return a new anonymous inode descriptor with the restricted access to the main PCM device to satisfy the SELinux requirements / security policies? It might be more nice and simple solution than to implement the full dma-buf interface for the ALSA's PCM devices.
That certainly works for me so long as the security people are happy.
Question: The dma-buf also implements the fencing, but I am not able to determine, if this mechanism is used in android [1]. It may allow concurrent mmap and synchronize apps - but the sound server should manage the access to the DMA buffer anyway. In my opinion, it makes much sense for the video-pipes when the hardware does some accelerations (encoding/decoding).
We had the same discuission off list and couldn't think of a need for that feature in the audio context but left it in as it's already there with dma-buf so there's no real cost to implementing it and we weren't sure we weren't missing something.