erik quanstrom wrote: > this part is confusing. plan 9 has always maintained 1 independent > namespace per process group. so i'm surethat there's more to it > than this. could you go into detail on this?
You are right I was using terminology loosely here. What I mean by "namespace" in this context is the idea of a group of processes which share a common namespace, and combine to create a user environment. In other words, in a normal Plan 9 system, most of the processes are aligned with the same root file system that the kernel acquired at boot, and I'm loosely referring to this common root as "the namespace." When I talk about running "multiple independent namespaces" with ANTS, what I mean is using per-process namespace to do something similar to BSD jails or a virtual machine. The same Plan 9 kernel and machine can have groups of processes running with different root filesystems. If you create a group of processes that share a common root filesystem, you have a user environment. One thing that ANTS can do is to host multiple "namespace groups" on a single machine. Instead of having only one global namespace on the machine with a single common root, you can host independent user environments, each with a different root filesystem. I know you (and others) are busy with plenty of obligations, but the demos I have prepared with qemu vm images are designed to show in practice how you can make multiple independent user environments on a single plan 9 machine, then freely re-root which namespace you are using. So this part of ANTS is: running multiple userpsace environments on the same machine. You can do this because per-process namespaces means that you can have a totally different root file system for one group of processes than another. To make this really work, the ANTS 9pcram kernel does not attach to a root filesystem itself. The main flow of control of the kernel "stands back" from the user's namespace and does not attach to the same file descriptor that is the root of the user fs. This allows the main flow of control of the kernel to act as a kind of "namespace hypervisor" that can launch multiple indpendent user environments available at the same time on the same machine. To allow the user to actualy move between the different namespaces freely, I have a script and parameterized namespace file called "rerootwin" that acts as an instant Plan 9 chroot into a new filesystem. It avoids losing connection to the active window system by passing the devices through a srvfs. This means that even though you might have Bell Labs and 9front running on the same box at the same time, you can move back and forth at will, and enter either one from a lower-layer kernel-only namespace. This explanation was already kind of long and elaborate, but as I mentioned I have virtual machine images and demo walkthroughs so you can see how it actually works in practice, which is actually simpler than the verbal description. I'm not too good at balancing being precise and specific with keeping things brief, so I hope this was a good answer without too much unnecessary length. Ben Kidwell "mycroftiv"
