Clone this wiki locally
Device namespaces are an extension to existing Linux kernel namespaces, developed by Cellrox as part of its Thinvisor technology for lightweight virtualization for mobile devices. Device namespaces are based on research done at Columbia University1. Certain portions are copyrighted by Columbia University.
The work on Linux namespaces spans over more than a decade. Quoting LWN article on namespaces:
One of the overall goals of namespaces is to support the implementation of containers, a tool for lightweight virtualization (as well as other purposes) that provides a group of processes with the illusion that they are the only processes on the system.
Lightweight virtualizaton can also be greatly beneficial to run multiple virtual environments -called personas- on a single physical device; for instance, a dual-persona phone hosting two virtual phones on one smartphone: one personal and one for work. However, Linux namespaces fall short when it comes to virtualization of end-user devices (i.e., non-server scenarios), and in particular mobile devices. There are two main reasons for this shortcoming:
 Hardware diversity: end-user devices and particularly mobile devices, incorporate a plethora of peripherals that applications expect to be able to use, such as cameras, GPS, sensors, and many more. Currently, Linux namespaces virtualize only select hardware (storage and network) using logical devices. But this approach does not scale to virtualize arbitrary device drivers, or for the variety of peripherals and interfaces.
 Interactive usage: end-user devices are intended for interactive use, with the prevalent usage model being that users interact with one application at a time. With multiple personas (virtual environments) -e.g., virtual phones in our example above- on a single device, users really interact with only one persona at a time. In analogy to Linux processes in a terminal, entire personas can run in the foreground (interactive), or in the background (non-interactive), and the user may switch between these modes.
Device namespaces were specifically developed to address these two shortcomings. It complements Linux namespaces by filling the gaps to enable usable lightweight virtualization to end-user, and particularly mobile devices. Specifically, the role of device namespaces is twofold:
 Device namespaces create the illusion, for processes inside a persona (namespace), that they interact exclusively with a set of devices (physical or logical), and hides the fact that there are other processes in other personas (namespaces) interacting with the same set of device drivers.
 Device namespaces also introduce the concept of an active persona, which is a persona that a user can interact with, and the concept of switching personas to allow a user to interact with multiple personas, one at a time.
Device namespaces are free open source software, available under GNU GPL (License).
Device namespaces are the basis of Cellrox's Thinvisor, a commercial virtualization solution for Linux-based mobile devices offered by Cellrox. Thinvisor makes it possible for users to run multiple personas on a single mobile device. Thinvisor can transform regular mobile devices, like Android, into a multi-persona solution, where each persona looks and feels like a separate, individual instance of Android with the complete feature-set of the device.
To fulfill the two roles of device namespaces stated above, namely virtualize system device and multiplex access to them, device namespaces include the following two components:
or - A namespace for device MAJOR/MINOR and state isolation
When a process opens a special block/char device, the kernel provides (or denies access to) a handle to an entity associated with the requested MAJOR/MINOR tuple. Currently (without the proposed device namespaces), there is no way in Linux to abstract the MAJOR/MINOR namespace and provide handles to different objects depending on the namespace of the requesting process.
The fundamental goal of namespaces, as stated in LWN article "Namespaces in operation", is
wrap a particular global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource.
Device namespaces aim to apply this concept to device drivers too: to provide isolation of devices, including the MAJOR/MINOR and internal state of devices. This means, that two processes that request a particular resource in distinct namespaces will get handles to different objects, depending on the namespace to which they belong, each with its potentially own state.
The simplest example is the logical block loop
When a loop device is setup to a file in mount namespace A, it makes little
sense to allow access to that loop device, or even publish the fact that the
respective minor is assigned, in mount namespace B. An easy way to properly
virtualize the loop devices would be to keep a separate mapping of minors in use per
device namespace when creating loop devices.
Pseudo terminals, i.e. PTY
(/dev/ptmx, /dev/pts/X) device is an
example of a device that already got its own tailored namespace to virtualize
PTS devices created by users.
The devpts namespace patch
was upstreamed to
support multiple PTY namespaces so that the PTY index (i.e., the tty names) in one container is independent of the PTY indices of other containers. For instance this would allow each container to have a '/dev/pts/0' PTY and refer to different terminals.(Note, that
devptsis special in that it is mounted explicitly, allowing virtualization via separate mounts, unlike most other devices.)
or - A namespace for the active/non-active (foreground/background) concept
While originally aimed for servers, the namespaces abstraction is useful for end-users, too. For example, it can enable multiple interactive containers to run simultaneously on a single mobile device (which we call personas). In such scenarios, only one container -the one with which the user interacts- should control the input/output means of the device: output should come from the "current" persona only, and input should go to that persona only.
The concept of active namespace vs non-active namespace captures the notion of the "current" namespace - the namespace with which the user interacts. We also use the terms foreground persona vs background persona, in analogy to processes under job-control.
Supporting this modus operandi requires that input/output of devices be properly multiplexed. For some devices it also requires to keep virtual state for each namespace and perform context-switch when changing the active namespace.
Viewed from the eyes of the device (and device authors) - the behavior of the device can change depending on the context. For example, every namespace may use the framebuffer for full screen display, but only an active namespace may actually draw on it: the framebuffer device should propagate display updates from an active namespace, but store in a buffer otherwise. Similarly, the input subsystem should only allow "grabs" (request for exclusive use) of input devices for processes in an active namespace, and keep track of the "grab" request otherwise.
When the active namespace changes (e.g. the user switches to interact with another persona), the device should do a context-switch to reflect the change. For example, the framebuffer device should save the current display content, and restore the saved content of the new active namespace. Similarly, the input subsystem should undo the current "grabs", and carry out the "grabs" tracked for the new active namespace.
Device namespaces implement the notion of active namespace, and provides an interface for userspace to query and modify the current active namespace.
- For detailed description of the patches, proceed to the device namespace patches page.
- To explore the patches and the code, proceed to the device namespaces patches repository.
 "Cells: A Virtual Mobile Smartphone Architecture". Jeremy Andrus, Christoffer Dall, Alexander Van’t Hof, Oren Laadan, Jason Nieh. Proceedings of the 23rd ACM Symposium on Operating Systems Principles (SOSP 2011). Cascais, Portugal, October, 2011.