Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <2737@auspex.UUCP>
Date: 19 Dec 89 00:07:28 GMT
References: <11383@csli.Stanford.EDU> <1989Dec12.005555.20618@virtech.uucp> <21223@mimsy.umd.edu> <1989Dec12.053453.497@virtech.uucp> <1989Dec13.225842.3502@squazmo.solbourne.com>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21

>When the BRL 'System-V-under-BSD' emulation code hit the street, people 
>had to re-think things. Simple subsumptive reasoning indicated that the 
>clear win was to jam as much of System V as possible into BSD rather than 
>the opposite. And so it went. The SunOS implemention (well, at least the 
>first one I saw source to -- Guy Harris, where are you on this?) used 
>dynamically allocated and mapped memory pages. The only thing that gets
>allocated at boot time is an array of SHMMNI struct shmid_ds's for use
>as the descriptors.

If you're talking about SunOS 3.x, it didn't allocate shared memory at
boot time as I remember, but it *did* allocate it as wired-down physical
memory, not pageable memory.  SunOS 4.x pages shared memory segments; it
has a VM implementation that bears little, if any, resemblance to BSD's
(but does bear more than a little resemblance to S5R4's, given that
S5R4's is derived from SunOS 4.x's). 

Non-paging System V releases from AT&T allocated it as wired-down
physical memory; paging releases, as I remember (including "System V
Release 2 Version 2" or whatever the paging VAX release was called),
page shared memory.  That didn't stem from jamming S5 into BSD, since
what jamming occurred there was in the other direction....