jas@ernie.Berkeley.EDU (Jim Shankland) (04/26/89)
In article <13601@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >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. > >[etc.] Naah. They just didn't have the imagination to do it right. The IPC namespace business is an abomination. I can't imagine it as a first step toward a newer, grander vision. (Of course, that's what they said about *Dejeuner sur l'herbe*, too.) Take a look at mmap() in SunOS 4.0 (it didn't actually originate with Sun); that's a pretty clean way to do shared memory. And I never have figured out what message queues give you that you couldn't get by tuning up pipe semantics a little. To my mind, the SysV IPC stuff fairly screams: "glued on to the system at the last minute as an afterthought." Your speculation on their line of reasoning is novel, but even with my most charitable hat on, I just can't see it. Anybody who actually helped design this stuff care to comment? Jim Shankland jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
ed@mtxinu.COM (Ed Gould) (04/27/89)
>>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 ... >Naah. They just didn't have the imagination to do it right. The IPC >namespace business is an abomination. ... >To my mind, the SysV IPC stuff fairly screams: "glued on to the system >at the last minute as an afterthought." The history of Unix development and support gives some clues to understanding some of the (mis)features in System V. While AT&T was prohibited, by a consent decree signed between AT&T and the Justice Department, from being in the computer business, there was a group with in the (then) Bell System called the "Unix Support Group" (USG). USG's job was to support Unix for the Bell Operating Companies and other internal Bell System uses. They were not trying to develop general-purpose systems, but to meet the specific needs of their users. System V shared memory is an example of something that was developed for some particular Bell need. In fact, there were two completely different shared memory schemes at one time - one on PDP11s and one on VAXen - that were designed for entirely different purposes. Needless to say, they were completely incompatible with each other. Current System V shared memory - if I'm not mistaken - is essentially the VAX version. It wasn't "glued on ... at the last minute," but neither was it designed originally as a general-purpose mechanism. It served some specific need within Bell before there were other available models from which to choose. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
dwc@cbnewsh.ATT.COM (Malaclypse the Elder) (04/27/89)
In article <837@mtxinu.UUCP>, ed@mtxinu.COM (Ed Gould) writes: > > The history of Unix development and support gives some clues to > understanding some of the (mis)features in System V. While AT&T was > prohibited, by a consent decree signed between AT&T and the Justice > Department, from being in the computer business, there was a group with > in the (then) Bell System called the "Unix Support Group" (USG). USG's > job was to support Unix for the Bell Operating Companies and other > internal Bell System uses. They were not trying to develop > general-purpose systems, but to meet the specific needs of their > users. > as i remember it, because of the void in such services, there were a number of different implementations of shared memory and messages. the bell labs comp centers (who were one of the largest "users" of system III at the time) were threatening to adopt the ipc implementations of the computer center in columbus (i believe). this perhaps forced the USG to design something of their own. i never used the columbus implementation of ipc (i think it was called MAUS) but it was the perception that what the USG implemented was more general. i'm not sure why they did not choose to FORCE a mapping between filesystem names and message queues or semaphores since one of the recommended ways to generate a unique key to create these things is to use ftok(). having file descriptors would also have made it easier to do polling for input from either message queues, semaphores or regular files. then again it isn't to late to do that and have all the shm_ops and the sema_ops just library calls for compatibility. then again maybe not. all this is from cloudy memory. my memory of events before DIVESTITURE are hazy (perhaps also idyllic). danny chen att!hocus!dwc
ka@june.cs.washington.edu (Kenneth Almquist) (04/27/89)
The shared memory the PDP-11 version of System V does actually use file names to refer to segments. On the other hand, if you want to change the size of a segment, or add a new segment, you have to rebuild the kernel. As Ed noted, the System V IPC was not designed as a general purpose mechanism. I might add that a goal of the original design was to avoid penalizing users who just wanted to do normal UNIX stuff. All the IPC system calls are (or at least were) optional, so that you didn't have to link them into the kernel if you just wanted to run a vanilla UNIX time sharing system. This is certainly one reason for not having the IPC code touch the file system. (The PDP-11 shared memory was implemented as a pseudo-device.) The decision to include IPC in the SVID (assuming it's there; someone correct me if I'm wrong) really contradicts the original view of the purpose of the System V IPC. Kenneth Almquist
kalash@starnine.UUCP (Joe Kalash) (04/28/89)
In article <8015@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: > >The decision to include IPC in the SVID (assuming it's there; someone >correct me if I'm wrong) really contradicts the original view of the >purpose of the System V IPC. The System V IPC is in the SVID, however it is part of the optional kernal extension module (as is shared memory, and semaphores). Joe Kalash uunet!starnine!kalash kalash@starnine.com Disclaimer: StarNine knows nothing about what I am saying.
devine@shodha.dec.com (Bob Devine) (04/28/89)
The story I heard is that System V IPC comes from a version that the folks at AT&T/Columbus put together for operations support. Even before System III, they had a special version of Unix that had an implementation of messages, shared memory and semaphores. A more general IPC was added to System V for them just so there wouldn't be a need to have two Unixes supported. Bob Devine
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>The decision to include IPC in the SVID (assuming it's there; someone >correct me if I'm wrong) really contradicts the original view of the >purpose of the System V IPC. It is in an optional section of the SVID, so SVID compliance doesn't oblige you to offer it, nor does it oblige you to make it a feature that can't be configured out (older S5's let you configure it out, I assume newer ones do as well; SunOS lets you configure it out, and I suspect other systems also do). There are applications that use it, which is I guess one reason why it's in the SVID; there may be better mechanisms, but if there are N different ones this might make life more diffcult for people who want to use those mechanisms on different machines. (Note: I'm neither saying that its inclusion in the SVID is good nor bad, and I have no interest in participating in a debate on that subject.)