Subject: Re: mapping shared memory at a fixed address
To: Stephan Uphoff <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 02/08/2005 09:47:10
Content-Type: text/plain; charset=us-ascii
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----