Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!jsq
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <529@usenix.ORG>
Date: 20 Sep 90 12:48:04 GMT
References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: Teltronics/TCT, Sarasota, FL
Lines: 58
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: chip@tct.uucp (Chip Salzenberg)

According to fouts@bozeman.bozeman.ingr (Martin Fouts):
>According to chip@tct.uucp (Chip Salzenberg):
>> Research Unix [...] put *more things [in the filesystem],
>> including processes (via the /proc pseudo-directory).
>
>The value of proc in the file system are debatable.  Certain debugging
>tools are easier to hang on an fcntl certain others are not.

With /proc, some things are much easier.  (Getting a list of all
active pids, for example.)  Nothing, however, is harder.  A big win.

>However, the presences of the proc file system is not a strong arguement
>for the inclusion of othere features in the file system.

I disagree.  I consider it an excellent example of how the designers
of Unix realize that all named objects potentially visible to more
than one process belong in the filesystem namespace.

>Unix programming has a history of using the filesystem for some things
>and not using it for others.  For example, I can demonstrate a
>semantic under which it is possible to put the time of day clock into
>the file system ...

Of course.  But in the absense of remotely mounted filesystems --
which V7 Unix was not designed to support -- there is only one time of
day, so it needs no name.  (I wouldn't be surprised if Plan 9 has a
/dev/timeofday, however.)

>... not all functions which might have been placed in the
>filesystem automatically have.

This observation is correct.  But it is clear that the designers of
Research Unix have used the filesystem for everything that needs a
name, and they continue to do so.  Their work asks, "Why have multiple
namespaces?"  Plan 9 asks the question again, and with a megaphone.

>Because of the way network connections are made, I have been
>convinced by networking experts (who are familiar with the "Unix
>style") that the filesystem namespace does not have a good semantic
>match for the network name space.

Carried to its logical conclusion, this argument would invalidate
special files and named pipes, since they also lack a "good semantic
match" with flat files.  In fact, the only entities with a "good
semantic match" for flat files are -- you guessed it -- flat files.

So, how do we program in such a system?  We use its elegant interface
-- or should I say "interfaces"?  Plain files, devices, IPCs, and
network connections each have a semantically accurate interface, which
unfortunately makes it different from all others.

This is progress?  "Forward into the past!"
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 119