Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: example of general name space usage
Message-ID: <4932:Oct902:45:5390@kramden.acf.nyu.edu>
Date: 9 Oct 90 02:45:53 GMT
References: <14060@smoke.BRL.MIL>
Organization: IR
Lines: 31

In article <14060@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In some newsgroup, probably either this one or comp.std.unix, there has
> recently been some debate about the utility of having all objects in a
> single uniform name space.  While reading the paper "Plan 9 from Bell
> Labs", I came across a marvelous example of why this IS a good idea:
> A first draft of the "ps" process on Plan 9 would be just
> 	cat /proc/*/status
> Think about it..

So what? It would be just as easy if /proc were in a separate namespace,
and had a program other than cat to open process files. In fact, one can
easily argue that a fixed, two-level structure would be a much more
natural way to deal with processes. /proc does fit reasonably well into
the filesystem, because processes are static (they don't appear or
disappear until they take explicit action), local, and reliable; but
unreliable, dynamic, remote I/O objects probably don't belong in the
same namespace.

Very few programs actually need open(). The ones that use it become more
flexible when you take away open() and use existing file descriptors,
though you do need one program---I nominate the shell---to deal with
namespaces.

A marvelous example of the flexibility you get by using file descriptors
as the powerful abstraction they are: A recent article in alt.security
mentions an implementation of ACLs under UNIX. Did the implementor have
to change the kernel? No! Did he have to change programs to make them
cooperate with the ACL structure? No! He just had a setuid program do
the dirty work and *pass the file descriptor to your program*.

---Dan