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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
