From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  9 May 2000 13:53:36 -0400
From: Alexander Viro viro@math.psu.edu
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Topicbox-Message-UUID: a91cc1e8-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000509175336.KDnitLqNsM9cu82ob5qegBj5YvXB7Jn932TqtF5Csck@z>



On Tue, 9 May 2000, rob pike wrote:

> Making the command do the work instead of the system call gets you
> into the kind of problems that confuse people.  If bind only works
> cleanly as a command, then programs that call on it through the
> library will behave differently from seemingly equivalent shell
> scripts.  Phooey.  Why in the shell can I cd somewhere but not chdir
> there?  Because cd is a bucket of shell magic, but chdir is a system
> call.  Such distinctions don't make a system perspicuous.

OK, here you obviously have a point. Recursive variant added, returns
-ELOOP on loop creation.

> This discussion is about implementation.  Back up a level.  What are
> your goals?  Plan 9's per-process name space builds on and interacts
> with other system facilities to get its power.  Linux doesn't have
> user-level file systems, for example; what's the advantage?  If all

First of all, it has, but that's not a real point. The thing I've
described came from the need to clean VFS up and close a bunch of really
unpleasant races. The fact that it gives something rather similar to
namespaces was a win, but frankly, I've realized where it was moving to
pretty late in the game.

There is a bunch of stuff that immediately wins from that. Horror knows as
devfs, for one. Another monster: Linux procfs. Been there, cleaned parts
of that and it was _not_ a pretty work. It also allows to keep the whole
directory tree in dcache (seriously cuts down on the cruft, removes a lot
of code duplication), etc.

Filesystems in the kernel are getting more light-weight than they used to
be and that's a good thing, e.g. because that allows drivers to populate
their own small trees without bothering with a lot of mess. And if you
will look at the contents of /proc on a Linux box you'll see why it is a
Good Thing(tm) for us - taking the bloody thing apart would be a big win.

IOW, what happens is a big cruftectomy. Since results happen to resemble
the stuff you've done in Plan 9 I'm obviously interested in looking into
your ideas - you've been in these places and have a pretty rare thing.
Taste, that is...

> you get is the ability to replace $PATH with a unioned /bin, it's not

Ahem... Thank you, but there are more serious needs.

> worth the trouble.  If on the other hand you want to build interesting
> name spaces that can be shared across the network, as in Plan 9, your
> design leaves a lot to be desired.

Maybe. Again, the main goal was to clean the things up and fix a bunch of
very unpleasant holes. The fact that results resemble namespaces was,
well, interesting enough. If we can do per-process namespaces easily
(read: it comes for free) - well, why not? I can see uses for that beyond
the extermination of $PATH. I certainly see uses for these mechanisms in
the kernel. And doing userland filesystems is definitely possible - such
things exist.