On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx>wrote: > Oren Laadan <orenl@xxxxxxxxxxx> writes: > > > Hi Serge, > > > > > > On Thu, Aug 22, 2013 at 2:21 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx > >wrote: > > > >> Quoting Oren Laadan (orenl@xxxxxxxxxxx): > >> > Hi everyone! > >> > > >> > We [1] have been working on bringing lightweight virtualization to > >> > Linux-based mobile devices like Android (or other Linux-based devices > >> with > >> > diverse I/O) and want to share our solution: device namespaces. > >> > > >> > Imagine you could run several instances of your favorite mobile OS or > >> other > >> > distributions in isolated containers, each under the impression of > having > >> > exclusive access to device drivers; Interact and switch between them > >> within > >> > a blink, no flashing, no reboot. > >> > > >> > Device namespaces are an extension to existing Linux kernel namespaces > >> that > >> > brings lightweight virtualization to Linux-based end-user devices, > >> > primarily mobile devices. > >> > Device namespaces introduce a private and virtual namespace for device > >> > drivers to create the illusion for a process group that it interacts > >> > exclusively with a set of drivers. Device namespaces also introduce > the > >> > concepts of an “active” namespace with which a user interacts, vs > >> > “non-active” namespaces that run in the background, and the ability to > >> > switch between them.[2] > >> > >> Note that unless I'm misunderstanding what you're saying here, this is > >> also what net_ns does. A netns can exist with no processes so long as > >> you've bound its /proc/$$/ns/net somewhere. You can then re-enter that > >> ns using ns_attach. I haven't looked closely enough yet to see whether > >> you should be (or are) using the same interface. > >> > >> > > To illustrate the need for device namespaces, consider the use case of > > running two containers of your favorite OS (say, Android), on a single > > physical phone. As a user, you either work in one container, or in the > > other, and you will want to be able to switch between them (just like > with > > apps on mobile devices: you interact with one application at a time, and > > switch between them). > > > > See here for a demo of how it works: http://vimeo.com/60113683 > > > > To accomplish this, device namespaces solve two shortcomings of existing > > namespaces: > > > > 1. A namespace for device drivers: each (Android) container needs a > > private view of all devices. This includes logical drivers, like binder > (in > > Android) but also loop device; and physical devices, like the framebuffer > > and the touch-screen. > > > > In other words, device namespaces virtualize the _major/minor_ and the > > _state_ of device drivers. With the exception of VFS, network, and PTY > > (note: all three offer/are virtual devices), device drivers are otherwise > > not isolated between containers. > > > > 2. A namespace for interactive scenarios: a namespace can be "active" - > it > > has access to the hardware, e.g. display and touch-screen. This will be > the > > container with which the user is interacting right now. Otherwise a > > namespace is "non-active" - it still runs in the background, but can > > neither alter the display nor receive input from the touch-screen. > > Switching to another container means a context switch in the relevant > > drivers, so that they restore the state and now "obey" the other > namespace. > > > > You can also think about the "active" namespace as foreground, and the > > "non-active" as background, akin to foreground/background processes in a > > terminal with job-control. Similar to how a terminal delivers input to > the > > foreground task only but not to the background tasks - this is enforced > by > > the new device namespace. > > > > More details on this use-case are in the wiki: > > https://github.com/Cellrox/devns-patches/wiki/Thinvisor). > > I think this is going to take some talking, and looking at code. > > 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. > > But we can talk at LPC and see what we can hash out. > Looking forward to that :-) Amir. > > Eric > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
