> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote: > > On Thu, Nov 15, 2018 at 2:54 PM gregkh@xxxxxxxxxxxxxxxxxxx > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > ... > > > > > > A number of us have talked about this in the plumbers Android track, and > > > a different proposal for how to solve this has been made that should be > > > much more resiliant. So I will drop this patch from my queue and wait > > > for the patches based on the discussions we had there. > > > > > > I think there's some notes/slides on the discussion online somewhere, > > > but it hasn't been published as the conference is still happening, > > > otherwise I would link to it here... > > > > Here is a link to the session where you can look at the slides [1]. > > There was consensus that "binderfs" (slide 5) was the most promising > > -- but would be behind a config option to provide backwards > > compatibility for non-container use-cases. > > > > The etherpad notes are at [2] (look at "Dynamically Allocated Binder > > Devices" section) > > > > Christian Brauner will be sending out more details. > > Ok, sorry for the delay I got caught up in other work. > > The idea is to implement binderfs which I'm starting to work on. > binderfs will be a separate pseudo-filesystem that will be mountable > per-ipc namespace. > This has the advantage that the ipc namespace is attached to the > superblock of the mount and can be easily retrieved by the binder > driver. It also implies that - in contrast to the proposed patch here - > an open() on a given binder device will not be able to change the ipc > namespace of said devices. The obvious corollary is that you can > bind-mount binder devices or the whole binderfs mount between different > ipc namespaces and given the right permissions (CAP_IPC_OWNER in the > owning userns of the ipcns) can see services on the host which is > something that people wanted to be able to do. > Additionally, each binderfs mount will come with a binder-control > device. This device is functionally similar to loop-control and will > allow for dynamic allocation (and possibly deallocation) of binder > devices. With this we can remove the restriction to hard-code the number > of binder devices at compile time. > Backwards compatibility can either be guaranteed by hiding binderfs > behind a compile flag or by special-casing the inital binderfs mount to > pre-create the standard binder devices. The jury is still out on this. > > Christian > Since you are working on this, I will withdraw this patch. We will evaluate whether to your solution in our environment after you implement it. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
