On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey <brian.star...@arm.com> wrote: > On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote: > > This is a *very early RFC* (it builds, that's all I'll say :) > > but I wanted to share it to get some initial feedback before I > > go down the rabit hole of trying to adapt the Android userland > > code to get this fully validated. > > > > This patchset tries to implement the per-heap devices for ION. > > The main benefit is that it avoids multiplexing heap operations > > through the /dev/ion interface, and allows for each heap to have > > its own permissions/sepolicy rules. > > In general, I've always thought that having a device node per-heap is > a bit messy for userspace. Multiplexing through the single node > doesn't seem like an insurmountable problem, but the point about
Hrm. I guess for me having a custom enumeration interface over ioctl seems less ideal compared to a directory list. > permissions/sepolicy is reasonably compelling if it's a real > requirement. What would be the reasons for that? Its a bit second hand for me, so hopefully I don't have it wrong. I've cc'ed some additional google folks and Benjamin for extra context, but my sense of it is that you may have some less-trusted code that we're fine with allocating system heap dma-bufs, but don't want to to be giving access to more limited heaps like carveout or cma, or more potentially security troubling heaps like system-contig. thanks -john _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel