Subject: Re: mapping shared memory at a fixed address
To: Stephan Uphoff <ups@tree.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 02/08/2005 09:47:10
--uAKRQypu60I7Lcqm
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 =
you=20
> > want, the new mmap won't work. The only way you could get around that w=
as=20
> > if you mapped the area and then had the process fork into a lot of=20
> > children. However the children could not exec..
>=20
> 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=
=20
around the hole.

While it hasn't been said, I assume that there are different programs that=
=20
need to use this same area. So the address would have to be chosen for all=
=20
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=
re=20
> > or pass relative pointers. Pass (intptr_t)ThePointer -=20
> > (intptr_t)MapAddress. Then in the recipient just add the stored or pass=
ed=20
> > integer to the local map address.
>=20
> 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,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCCPseWz+3JHUci9cRArUKAJ4h6IQEokEa9eVi8T0bccrse/fDEwCdEBP7
z7VT7/pvxwgyedY6LBAcVE8=
=SOoM
-----END PGP SIGNATURE-----

--uAKRQypu60I7Lcqm--