plan 9 Q&A

[ron minnich]

I was thinking of showing some examples of the power of name spaces in plan 9 in real life and this first one popped into my head. It's from our work on the supercomputers.

In 2006, we (Los Alamos, IBM, Vita Nuova, Bell Labs) ported Plan 9 to the IBM Blue Gene supercomputer. These were lightweight nodes. The first one we used had 667 Mhz. CPUs with 512 mb memory at then end of a very thin pipe (the thick 18 Gbyte/second pipe, the torus, didn't have connectivity "outside").

Since the BG machines we were using were in a 3D torus, we set up the IP address space so that the nodes were addressed as 10.x.y.z+1, e.g.

10.0.0.1 was the node at [0,0,0] (10.0.0.0 not being  usable node address].

This left enough room for about 2^22 nodes. 

Suppose we want to debug a process on a BG node. We have the option of writing a gdb server, but that's not a very good option: you write a gdb server, and you can do one thing with it: serve gdb. It's not the Unix model, where you do one thing that can serve many purposes. 

A much better path is available: 

import 10.0.0.1 /proc /proc

This brings the /proc of 10.0.0.1 into the name space in of the process I'm in as /proc. This doesn't change any other process; just the one I'm in. It's just like the CLONE_NEWNS flag in linux.

At this point, I can do all sorts of  things:

ps (because ps uses file IO in /proc with strings)

strace (because strace uses file IO in /proc with strings)

debug (because debug uses file IO in /proc with strings)

kill (...)

and so on. Any command that might affect /proc will work, but it will be working on the /proc in the remote node.

Note that kill in plan 9 is a shell script, that takes a name or pid, and in the end does

echo kill > /proc/pid/ctl

In this case, the shell and all its children run on the local node and manipulate processes in the same way they would locally; the effect on the remote node is because of the import of /proc.

This all works because the control and status messages in Plan 9 are text. There's no strace system call, kill system call, and no special system calls are needed for debug. It's why Plan 9 has always had about 40 system calls.

As a side note, Plan 9 got heterogeneity right; it was never a big deal to run a debugger on a 386 to debug a Power machine. It's nowhere near the level of complexity you seen in Linux to do the same thing. Debugging cat on the bg/l node would be something like this:

debug /power/bin/cat

and it all works.

So, by doing one simple, general thing -- import /proc from a remote node into my name space -- I get all the capabilities on that remote node that I have locally, at very low cost (the 9p server that serves files and directories from the remote name space).

Rather than lots of little special purpose tools, I use one general purpose tool. And that in turn lets me do anything.

This only works really well, however, if you have command and status that works as strings. Hence the use of strings in many places in Plan 9 where Unix uses ints.

ron