home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
119
< prev
next >
Wrap
Internet Message Format
|
1990-12-05
|
3KB
From std-unix-request@uunet.uu.net Thu Sep 20 14:20:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
id AA10926; Thu, 20 Sep 90 14:20:46 -0400
Posted-Date: 20 Sep 90 12:48:04 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct!chip@cs.utexas.edu (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <529@usenix.ORG>
References: <488@usenix.ORG> <495@usenix.ORG> <523@usenix.ORG>
Sender: jsq@usenix.ORG
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: std-unix@uunet.uu.net
Date: 20 Sep 90 12:48:04 GMT
Reply-To: std-unix@uunet.uu.net
To: 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