🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.unix
Article #573

Re: Standards Update, IEEE 1003.4: Real-time Extensions

#573
From: Dan Bernstein
Date: Thu, 27 Sep 1990 02:06
52 lines
2856 bytes
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
Technical Details
Message-ID: <549@usenix.ORG>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!usenix!jsq
References: <539@usenix.ORG> <541@usenix.ORG> <545@usenix.ORG>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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