Standards Update, IEEE 1003.4: Real-time Extensions

[Chip Salzenberg]

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

According to fouts at bozeman.bozeman.ingr (Martin Fouts):
>According to chip at 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 at tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 119