Subject: Re: mapping shared memory at a fixed address
To: Stephan Uphoff <>
From: Bill Studenmund <>
List: netbsd-users
Date: 02/08/2005 09:47:10
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 08, 2005 at 11:51:10AM -0500, Stephan Uphoff wrote:
> On Mon, 2005-02-07 at 13:39, Bill Studenmund wrote:
> > On Fri, Feb 04, 2005 at 04:05:25PM -0800, Rahul Kulkarni wrote:
> > The problem is that if something else already is mapped at the address =
> > want, the new mmap won't work. The only way you could get around that w=
> > if you mapped the area and then had the process fork into a lot of=20
> > children. However the children could not exec..
> Mhhh .. maybe adding a zero filled section to the executable(s) at a
> fixed address would work.
> The executable could then unmap / remap the reserved address range.
> If this would work it probably needs a linker script from hell ;-).

The problem is that you'd have to have that linker script link everything=
around the hole.

While it hasn't been said, I assume that there are different programs that=
need to use this same area. So the address would have to be chosen for all=
programs and would need to not get in the way of them. :-)

> > If you want to store (or pass) pointers to things in the area, just sto=
> > or pass relative pointers. Pass (intptr_t)ThePointer -=20
> > (intptr_t)MapAddress. Then in the recipient just add the stored or pass=
> > integer to the local map address.
> This is probably the best approach.
> ( Especially in term of maintainability)=20
> Good macros can make converting from/to relative pointers (And error
> checking) really easy.

I really have to agree with this. You can make macros that will handle=20
storing and retrieving the relative pointers, so you won't have to worry=20
about it.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)