shmat() system call?

[terryl at osf.osf.org]

In article <2010 at lzga.ATT.COM> bogatko at lzga.ATT.COM (George Bogatko) writes:
>It doesn't seem to matter (on 3B's at least) if you malloc first, or
>have buffers either in data, bss, or stack.  The number that is
>returned apparently is a base reserved for shared memory
>attachments.  On 3B's, that number starts at 0xc1000000.
>I tried an experiment, and saw that the first attach occured at 0xc1000000,
>and the second occured at 0xc1020000 even though the segments were
>1000 bytes each.  The box has a mind of it's own.
>
>(On a 386, the attaches occured at 0x80400000, and 0x80800000).


     There might be a logical explanation for this behavior (about where
addresses get attached in shared memory segments).

     What could possibly be happening is that the DIFFERENCE between the
successive addresses could be the amount of memory that is capable of being
mapped with a PAGE of PTEs(Page Table Entries). If that is the case, then
not only are the processes sharing the same shared memory segment, but they
are also sharing the page of PTEs needed to map the segment.

     For example, using the numbers given for the 386 box above, one can see
that the difference is 0x400000 bytes, or 4 Mbytes of memory. This sure looks
suspiciously like a hardware page size of 4096 bytes, with each PTE taking up
4 bytes, providing 1024 PTEs per hardware page.

     The reason for doing this is to make bookkeeping of the shared memory
segment very simplistic; if it becomes necessary to move the shared memory
segment around in PHYSICAL memory, then all one has to do is modify the
page containing the PTEs for the segment, instead of tracking down each
process who has attached to the segment and then modifying the PTEs for each
individual process....