Re: RFC: Device Namespaces

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Oren Laadan <orenl@cellrox.com> writes:

> Hi Serge,
>
>
> On Thu, Aug 22, 2013 at 2:21 PM, Serge Hallyn <serge.hallyn@ubuntu.com>wrote:
>
>> Quoting Oren Laadan (orenl@cellrox.com):
>> > 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.

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.

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.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers