Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!indri!nic.MR.NET!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <13601@ncoast.ORG>
Date: 25 Apr 89 23:13:26 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <2001@unisoft.UUCP> <3746@ficc.uu.net> <13563@ncoast.ORG> <10051@smoke.BRL.MIL>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 49

As quoted from <10051@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn):
+---------------
| In article <13563@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
| >I find myself wondering if AT&T knew what it was doing after all....
| 
| Nah, the shm* objects are incompatible with fd-objects.
+---------------

I know.  In fact, that's part of my reasoning.

AT&T added a new object space (IPC objects) for shared memory, message
queues, and semaphores.  Presumably they had a reason not to want to use the
existing object space of file descriptors.  I can imagine the following
reasoning:

* File descriptors aren't quite general enough to do what we want.
* Changing fd's to be general (or perhaps flexible) enough will break things.
* We can design an object space that *is* flexible enough.
* Once we have done so, we can present them as separate object spaces for SVR2.
* In future versions, we can start to convert file descriptors into a class
  of IPC objects... eventually ending up with a single object space again.

Having done the latter, one could then use a single set of syscalls on the
entire space... allowing, for example, a "file" IPC object to be treated
either as a classical file, or mapped into the address space as shared memory,
or even as a message queue.  (And having message queues and files be semi-
equivalent raises the possibility of defining pipes in terms of such hybrid
objects.

Note also that it resolves the current problem of file system objects which
don't have file system names (e.g. sockets, or even pipes) and can even
provide a version of /dev/fd/n in the bargain.  The namespace of IPC objects
is visible (but can and should be made more so), but not tied to the file
system namespace.  I would suggest that (again) the IPC name space is more
general than the current file system name space (and again, incompatible).
Thus, we would again want to have them separate initially, then gradually
replace the less general with the more.  The IPC name space would need to be
revised, of course... 32 bits/name doesn't seem enough for large networks.

I dunno, it was just a thought.  On thinking it over, I find myself doubting
that AT&T (or Sun, now) would actually do something so sensible.  But the
possibility *does* exist.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser