9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Alexander Viro viro@math.psu.edu
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Date: Tue,  9 May 2000 13:53:36 -0400	[thread overview]
Message-ID: <20000509175336.KDnitLqNsM9cu82ob5qegBj5YvXB7Jn932TqtF5Csck@z> (raw)



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.





             reply	other threads:[~2000-05-09 17:53 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-09 17:53 Alexander [this message]
     [not found] <200005052042.QAA06869@er7.rutgers.edu>
2000-06-12 10:09 ` Tom E Arnold
  -- strict thread matches above, loose matches on Subject: below --
2000-05-10 12:22 rob
2000-05-10 10:17 Lucio
2000-05-10  9:49 Lucio
2000-05-10  8:51 Noel
2000-05-10  8:51 Douglas
2000-05-09 17:14 Alexander
2000-05-09 17:07 forsyth
2000-05-09 17:05 rob
2000-05-09 16:55 Russ
2000-05-09 16:31 Alexander
2000-05-09 16:18 Alexander
2000-05-09 16:15 rob
2000-05-09 16:10 dhog
2000-05-09 14:46 Alexander
2000-05-09 11:48 forsyth
2000-05-09  8:18 Douglas
2000-05-09  8:18 Ishwar
2000-05-08 20:35 Alexander
2000-05-08 20:11 Roman
2000-05-08 16:12 Russ
2000-05-08 13:45 Lucio
2000-05-08 13:05 Bengt
2000-05-08 12:48 Lucio
2000-05-08 12:09 Leo
2000-05-08  6:56 Bengt
2000-05-08  6:28 okamoto
2000-05-08  4:34 Russ
2000-05-08  4:33 rob
2000-05-08  3:55 okamoto
2000-05-06 12:47 Steve
2000-05-06  7:28 Lucio
2000-05-06  7:04 Lucio
2000-05-05 22:00 G.David
2000-05-05 20:53 Scott
2000-05-05 20:42 Anthony
2000-05-05 17:08 Lucio
2000-05-05 16:38 Lucio
2000-05-05 15:32 forsyth
2000-05-05 14:45 Lucio
2000-05-05 14:44 jmk
2000-05-05 14:42 Lucio
2000-05-05 14:20 Lucio
2000-05-05 14:14 Lucio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000509175336.KDnitLqNsM9cu82ob5qegBj5YvXB7Jn932TqtF5Csck@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).