[lxc-devel] RFC: Device Namespaces

[Amir Goldstein]

On Mon, Sep 9, 2013 at 2:51 AM, Eric W. Biederman <ebiederm at xmission.com>wrote:

> Amir Goldstein <amir at cellrox.com> writes:
>
> > On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman
> > <ebiederm at xmission.com> wrote:
> >
> > Hi Eric,
> >
> > If we can get people to take a quick look at the code before LPC
> > that could make the LPC discussions more effective.
> > Even looking at one of the subsystem patches can give a basic
> > idea of the work we have done:
> > https://github.com/Cellrox/linux/commits/devns-goldfish-3.4
> >
> >     I think you are talking about having wrappers around your devices
> >     so you
> >     can share.  Which is not the quite same problem the rest of us
> >     have been
> >     thinking of when talking about a device namespace.
> >
> > We are interested in all problems related to virtualizated view of
> > devices
> > inside a container, so let our work so far be a starting point to
> > discuss all of them.
> >
> >     My first impression is that this is better solved with more
> >     appropriate
> >     abstractions in userspace or in the kernel.
>
> As I read your code, you are solving the problem of one opener of a
> device among a group of openers being able to access a device at a time.
> Which leads to the question why can't the multiplexing happen in
> userspace?
>
> I think with your design it would not be possible to play a song in one
> device namespace while doing work in the other.  As a security model
> that isn't wrong but as someone trying to get work done that could be a
> real pain.
>

As a matter of fact, in our multi persona phone, you *can* hear music played
from background persona, but you *cannot* see images drawn from background
persona.


> The more common concern is to have devices we can use all of the time.
>
> There may be a need for a device namespace and multiplexing access to
> hardware devices makes that clearer.  So far nothing has risen to the
> level of we actually need a device namespace to do X.  Especially in an
> erra of hotplug and dynamic device numbers.
>
> It is arguable that you could do your kind of device multiplexing with a
> fuse device in userspace that implements your desired policy.
>

I agree about it being arguable :-)
We shall present our arguments on LPC.


>
> And policy is where cell situtation seems to fall down because it hard
> codes one specific policy into the kernel, and a policy most situations
> don't find useful.
>
>
It's true that for our product, we have made hardcoded policy decisions in
our kernel
patches, but that was just as a proof of concept for the technique.

We do envision being able to dynamically assign a device to a specific devns
(e.g. block,loop) keep a device shared between multi devns (e.g. audio)
and in addition to that, being able to multiplex a device between multi
devns (e.g. framebuffer)



> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130910/c70a7c6a/attachment.html>