<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, <a href="tel:2013" value="+9722013" target="_blank">2013</a> at 7:50 PM, Eric W. Biederman <span dir="ltr"><<a href="mailto:ebiederm@xmission.com" target="_blank">ebiederm@xmission.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>Oren Laadan <<a href="mailto:orenl@cellrox.com" target="_blank">orenl@cellrox.com</a>> writes:<br>
<br>
> Hi Serge,<br>
><br>
><br>
> On Thu, Aug 22, <a href="tel:2013" value="+9722013" target="_blank">2013</a> at 2:21 PM, Serge Hallyn <<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>>wrote:<br>
><br>
>> Quoting Oren Laadan (<a href="mailto:orenl@cellrox.com" target="_blank">orenl@cellrox.com</a>):<br>
>> > Hi everyone!<br>
>> ><br>
>> > We [1] have been working on bringing lightweight virtualization to<br>
>> > Linux-based mobile devices like Android (or other Linux-based devices<br>
>> with<br>
>> > diverse I/O) and want to share our solution: device namespaces.<br>
>> ><br>
>> > Imagine you could run several instances of your favorite mobile OS or<br>
>> other<br>
>> > distributions in isolated containers, each under the impression of having<br>
>> > exclusive access to device drivers; Interact and switch between them<br>
>> within<br>
>> > a blink, no flashing, no reboot.<br>
>> ><br>
>> > Device namespaces are an extension to existing Linux kernel namespaces<br>
>> that<br>
>> > brings lightweight virtualization to Linux-based end-user devices,<br>
>> > primarily mobile devices.<br>
>> > Device namespaces introduce a private and virtual namespace for device<br>
>> > drivers to create the illusion for a process group that it interacts<br>
>> > exclusively with a set of drivers. Device namespaces also introduce the<br>
>> > concepts of an “active” namespace with which a user interacts, vs<br>
>> > “non-active” namespaces that run in the background, and the ability to<br>
>> > switch between them.[2]<br>
>><br>
>> Note that unless I'm misunderstanding what you're saying here, this is<br>
>> also what net_ns does. A netns can exist with no processes so long as<br>
>> you've bound its /proc/$$/ns/net somewhere. You can then re-enter that<br>
>> ns using ns_attach. I haven't looked closely enough yet to see whether<br>
>> you should be (or are) using the same interface.<br>
>><br>
>><br>
> To illustrate the need for device namespaces, consider the use case of<br>
> running two containers of your favorite OS (say, Android), on a single<br>
> physical phone. As a user, you either work in one container, or in the<br>
> other, and you will want to be able to switch between them (just like with<br>
> apps on mobile devices: you interact with one application at a time, and<br>
> switch between them).<br>
><br>
> See here for a demo of how it works: <a href="http://vimeo.com/60113683" target="_blank">http://vimeo.com/60113683</a><br>
><br>
> To accomplish this, device namespaces solve two shortcomings of existing<br>
> namespaces:<br>
><br>
> 1. A namespace for device drivers: each (Android) container needs a<br>
> private view of all devices. This includes logical drivers, like binder (in<br>
> Android) but also loop device; and physical devices, like the framebuffer<br>
> and the touch-screen.<br>
><br>
> In other words, device namespaces virtualize the _major/minor_ and the<br>
> _state_ of device drivers. With the exception of VFS, network, and PTY<br>
> (note: all three offer/are virtual devices), device drivers are otherwise<br>
> not isolated between containers.<br>
><br>
> 2. A namespace for interactive scenarios: a namespace can be "active" - it<br>
> has access to the hardware, e.g. display and touch-screen. This will be the<br>
> container with which the user is interacting right now. Otherwise a<br>
> namespace is "non-active" - it still runs in the background, but can<br>
> neither alter the display nor receive input from the touch-screen.<br>
> Switching to another container means a context switch in the relevant<br>
> drivers, so that they restore the state and now "obey" the other namespace.<br>
><br>
> You can also think about the "active" namespace as foreground, and the<br>
> "non-active" as background, akin to foreground/background processes in a<br>
> terminal with job-control. Similar to how a terminal delivers input to the<br>
> foreground task only but not to the background tasks - this is enforced by<br>
> the new device namespace.<br>
><br>
> More details on this use-case are in the wiki:<br>
> <a href="https://github.com/Cellrox/devns-patches/wiki/Thinvisor" target="_blank">https://github.com/Cellrox/devns-patches/wiki/Thinvisor</a>).<br>
<br>
</div></div>I think this is going to take some talking, and looking at code.<br>
<br></blockquote><div><br></div><div>Hi Eric,</div><div><br></div><div>If we can get people to take a quick look at the code before LPC</div><div>that could make the LPC discussions more effective.</div><div>Even looking at one of the subsystem patches can give a basic</div>
<div>idea of the work we have done:</div><div><a href="https://github.com/Cellrox/linux/commits/devns-goldfish-3.4" target="_blank">https://github.com/Cellrox/linux/commits/devns-goldfish-3.4</a><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think you are talking about having wrappers around your devices so you<br>
can share. Which is not the quite same problem the rest of us have been<br>
thinking of when talking about a device namespace.<br></blockquote><div><br></div><div>We are interested in all problems related to virtualizated view of devices</div><div>inside a container, so let our work so far be a starting point to discuss all of them.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
My first impression is that this is better solved with more appropriate<br>
abstractions in userspace or in the kernel.<br>
<br>
But we can talk at LPC and see what we can hash out.<br></blockquote><div><br></div><div>Looking forward to that :-)</div><div><br></div><div>Amir.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
Eric<br>
</font></span><div><div>_______________________________________________<br>
Containers mailing list<br>
<a href="mailto:Containers@lists.linux-foundation.org" target="_blank">Containers@lists.linux-foundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/containers" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/containers</a></div></div></blockquote></div><br></div></div>