Standards Update, IEEE 1003.4: Real-time Extensions

Peter da Silva peter at ficc.ferranti.com
Mon Sep 24 01:48:18 AEST 1990


Submitted-by: peter at ficc.ferranti.com (Peter da Silva)

In article <523 at usenix.ORG> fouts at bozeman.bozeman.ingr (Martin Fouts) writes:
> 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)

You mean things that don't operate like a single bidirectional stream, like
pipes? It's funny that the sockets that *do* behave that way are not in the
file system, while UNIX-domain sockets (which have two ends on the local box)
are.

> Unix programming has a history of using the filesystem for some things
> and not using it for others.

UNIX programming has a history of using whatever ad-hoc hacks were needed
to get things working. It's full of evolutionary dead-ends... some of which
have been discarded (multiplexed files) and some of which have been patched
up and overloaded (file protection bits). But where things have moved closer
to the underlying principles (everything is a file, for example) it's become
the better for it.

> 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.

This seems reasonable, but the rest is a pure argument from authority.
Could you repeat these arguments for the benefit of hose of us who don't
have the good fortune to know these networking experts you speak of?

[ Everyone involved in this discussion, please try to keep it in a
technical, not a personal, vein.  -mod ]

-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter at ferranti.com

Volume-Number: Volume 21, Number 127



More information about the Comp.std.unix mailing list