[alsa-devel] [PATCH 0/2] ALSA: pcm: implement the anonymous dup v3

[Phil Burk]

Thank you all for sorting this out. It seems like we are moving in a really
good direction.

> I agree. We can have just two modes for the beginning:
> a) full one (useful for testing)
> b) buffer only (allow just sound data mmap)

The full one is would also be used by the HAL for querying the DSP position.

>  if we should use different names (like anon_inode:snd-pcm and
anon_inode:snd-pcm-buffer)

That would be helpful.

I have attached a revised requirements doc. The original doc was more of a
HowTo for OEMs to create the "anon_inode:dmabuf" FD.. This clarifies the
requirements and allows for the use of "anon_inode:snd-pcm*". It should
match what we have arrived at by discussion. Let me know if it makes sense.

Thanks,
Phil Burk


On Fri, Feb 1, 2019 at 5:01 AM Mark Brown <broonie at kernel.org> wrote:

> On Fri, Feb 01, 2019 at 10:55:24AM +0100, Jaroslav Kysela wrote:
>
> > I agree. We can have just two modes for the beginning:
>
> > a) full one (useful for testing)
> > b) buffer only (allow just sound data mmap)
>
> > The question, if we should use different names (line anon_inode:snd-pcm
> > and anon_inode:snd-pcm-buffer) for the anonymous inodes remains. I
> > believe it might be good to distinguish this to allow the proper SELinux
> > audit.
>
> I agree that the separte names seems better, it gives more flexibility
> and control to people writing policies.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RequirementsSecureMMapFileDescriptor.pdf
Type: application/pdf
Size: 31320 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20190201/2db20a3c/attachment-0001.pdf>