Path: utzoo!attcan!uunet!usenix!jsq
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <549@usenix.ORG>
Date: 27 Sep 90 02:06:52 GMT
References: <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: IR
Lines: 52
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)

In article <545@usenix.ORG> ske@pkmab.se (Kristoffer Eriksson) writes:
> In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
    [ file descriptors are general; the filesystem is not ]
> What prevents us from inventing a few additional filesystem operations
> that ARE general enough?

That's a good question. I am willing to believe that a somewhat
different kind of filesystem could sensibly handle I/O objects that are
neither reliable nor local. I find it somewhat harder to believe that
the concept of a filesystem can reasonably reflect dynamic I/O:
information placed into a filesystem should stick around until another
explicit action.

In any case, you'll have to invent those operations first.

> I think the important thing about the filesystem abstraction that is being
> debated here, is the idea of a common name space,

Here's what I thought upon reading this.

First: ``A common name space is irrelevant to the most important
properties of a filesystem.''

Second: ``A common name space is impossible.''

And finally: ``We already have a common name space.''

Let me explain. My first thought was that the basic purpose of a
filesystem---to provide reliable, static, local I/O---didn't require a
common name space. As long as there's *some* way to achieve that goal,
you have a filesystem. UNIX has not only some way, but a uniform,
consistent, powerful way: file descriptors.

But that's dodging your question. Just because a common name space is
irrelevant to I/O doesn't mean that it may not be helpful for some other
reason. My second thought was that the kind of name space you want is
impossible. You want to include network objects, but no system can
possibly keep track of the tens of thousands of ports under dozens of
protocols on hundreds of thousands of computer. It's just too big.

But that's not what you're looking for. Although the name space is huge,
any one computer only looks at a tiny corner of that space. You only
need to see ``current'' names. My third thought: We already have that
common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
is in that space. (proc,1) is in that space. No system call uses this
common name space, but it's there. Use it at will.

---Dan

Volume-Number: Volume 21, Number 137