Path: utzoo!mnetor!uunet!mcvax!enea!sems!love
From: love@sems.SE (Love Feuer UniVox Inc.)
Newsgroups: comp.unix.wizards
Subject: Re: Motorola Sys V help
Message-ID: <224@sems.SE>
Date: 21 Feb 88 11:22:38 GMT
References: <106600031@datacube> <4345@mcdchg.UUCP>
Reply-To: love@sems.UUCP (Love Feuer)
Organization: SEMS AB, Stockholm, Sweden
Lines: 48
Keywords: NCR shared memory.

In article <4345@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes:
>ftw@datacube.UUCP writes:
>> As a side note, I have heard from a Motorola FAE that shared memory under
>> R3V3 is broken in some significant fashion.
>> ...
>
>The only "shared memory" bug I am aware of is actually in the "ipcs" command.
>
> [ Rest of article deleted ]
>
 I have never got shared memory to work with all its features on the
NCR T32 (68020) SysV.2. The problem I had was to get it attached to another
place in memory than some kilobytes after the break point of the
process. I tried to make the shared segment as an overlay of an array
of chars, but the only thing I got was "Illegal address".

 And then there was the SHMLBA thing. The manual entry for shmop(2)
tells that SHMLBA was used if the SHM_RND flag was set in the
third argument of shmat(2). If SHM_RND was set, the segment was attached to
(char *) (The_address_you_gave_as_an_argument - T_a_y_g_a_a_a modulus SHMLBA).
 Just one problem. SHMLBA was a macro for ptob(1). A very nice function,
which sadly enough was not represented by the C-library, and not
mentioned anywhere in programers ref. man. for the T32. 

  The biggest pain with having a shared memory segment attached a few
kilos after your break point, is that malloc and similar things raises
the break point to obtain more memory. Sooner or later they will run
into the shared memory segment and stop due to a check in (s)brk(2)
which prevents a nice mixup with other processes' memory. This means
that malloc will only be able to use the memory between the 
break point and the start of a shared mem. seg., which is 16 or 32k if 
my memory serves me.
 The solution to this is to move the break point forward a few hundred
kilobytes, attach the segment, and then move the break point back to its
original point. But you are still limited to a few hundred Kbytes of
malloc and not the maxmimum of a process which is defined in config.h

 This problem might be more specific for NCR than UNIX, but I 
thought you should know. There is even a chance that NCR have fixed
the bug(s) since I encountered them about a year ago.

------------------------------------------------------------------------------
In real life      : Love Feuer       Phone +46 8 21 62 78 | +46 8 723 10 87
Cyberspace attach : {your problem}!{uunet|cernvax|mcvax|unido}!enea!sems!love
Disclaimer        : cat laws > /dev/null
Famous last words: "Even I can do THAT!"        - or - 
		   "We are the members of the mighty adventure party. Join 
		    us or die."