Standards Update, IEEE 1003.4: Real-time Extensions

[Martin Fouts]

Submitted-by: fouts at bozeman.bozeman.ingr (Martin Fouts)

>>>>> On 7 Sep 90 15:23:19 GMT, chip at tct.uucp (Chip Salzenberg) said:

Chip> According to fouts at bozeman.bozeman.ingr (Martin Fouts):
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space ...

Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
Chip> the file system is, in the opinion of many, a bug.  It is a result of
Chip> Unix being extended by people who do not understand Unix.
                             ^-------------------------------^

My aren't we superior.  (;-) At one time, I believed that sockets
belonged in the filesystem name space.  I spent a long time arguing
this point with members of the networking community before they
convinced me that certain transient objects do not belong in that name
space.  (See below)

Chip> Research Unix, which is the result of continued development by the
Chip> creators of Unix, did not take things out of the filesystem.  To the
Chip> contrary, it put *more* things there, including processes (via the
Chip> /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.  However, the
presences of the proc file system is not a strong arguement for the
inclusion of othere features in the file system.

Chip> It is true that other operating systems get along without devices,
Chip> IPC, etc. in their filesystems.  That's fine for them; but it's not
Chip> relevant to Unix.  Unix programming has a history of relying on the
Chip> filesystem to take care of things that other systems handle as special
Chip> cases -- devices, for example.  The idea that devices can be files but
Chip> TCP/IP sockets cannot runs counter to all Unix experience.

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 and reference it by opening the i.e. /dev/timeofday
file.  Each time I read from that file, I would get the current time.
Via fcntls, I could extend this to handle timer functions.  It wasn't
done in Unix.  (I've done similar things in other OSs I've designed,
though.)

The whole point of the response which you partially quoted was to
remind the poster I was responding to that not all functions which
might have been placed in the filesystem automatically have.

Chip> The reason why I continue this discussion here, in comp.std.unix, is
Chip> that many Unix programmers hope that the people in the standardization
Chip> committees have learned from the out-of-filesystem mistake, and will
Chip> rectify it.
Chip> --

The reason I respond is that it is not automatically safe to assume
that something belongs in the file system because something else is
already there.  There is also an explicit problem not mentioned in
this discussion which is the distinction between filesystem name space
and filesystem semantics.  Sometimes there are objects which would be
reasonable to treat with filesystem semantics for which there is no
reasonable mechanism for introducing them into the filesystem name
space.  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.
 
Chip> Chip Salzenberg at Teltronics/TCT     <chip at tct.uucp>, <uunet!pdn!tct!chip>

Chip> Volume-Number: Volume 21, Number 89

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts at ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa

Volume-Number: Volume 21, Number 114