On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > userspace instance with subsequent relinquishment of privilege. At > > that point one has the freedom to implement all sorts of policy. > > If you look at the patch set that I sent yesterday it exactly has a > feature that makes it more lean for a privileged process to implement > a resource manager.
I continue to think, based on comments like this, that you should not implement tmps0 in the first revision either. That is also something we have to live with forever, and it can never become the 'policy limited' or 'unpriv safe' access point to the kernel. ie go back to something based on tmp0 with ioctl. This series should focus on allowing a user space RM to co-exist with the in-kernel services - lets try and tackle the idea of a policy-restricted or unpriv-safe cdev when someone comes up with a comprehensive proposal.. > The current patch set does not define policy. The simple policy > addition that could be added soon is the limit of connections > because it is easy to implement in non-intrusive way. It is also trivial for a userspace RM to limit the number of sessions or connections or otherwise to manage this limitation. It is hard to see why we'd need kernel support for this. The main issue from the kernel perspecitive is how to allow sessions to be used in-kernel and continue to make progress when they start to run out. Jason