Re: Towards a working "wine". [long]

My intuition says that mmap should ignore requests to map into the
existing brk region but not reject requests that are merely between the
existing brk region and the DS limit.

Is this what happens now?

-Jon

On Sat, 18 Jun 2005, Peter Edwards wrote:

> > >>... wine can call mmap(2) with MAP_FIXED and then if that fails try to
> > >>call mmap(2) without it and deal with consequences. This will provide
> > >>the same functionality but you won't get dependency on particular
> > >>FreeBSD version to get MAP_TRYFIXED define.
> > >>
> > >
> > >
> > > Nope: MAP_FIXED will unconditionally overwrite any existing mapping at
> > > the requested address.
> >
> > Hmm, the manpage doesn't mention anything of the effect. It only says:
> >
> > MAP_FIXED         Do not permit the system to select a different address
> >                    than the one specified.  If the specified address can-
> >                    not be used, mmap() will fail.  If MAP_FIXED is speci-
> >                    fied, addr must be a multiple of the pagesize.  Use of
> >                    this option is discouraged.
> >
> > Nothing about "overwriting any existing mapping". So that maybe
> > implementation should be adjusted to match documentation, not another
> > functionality be invented to workaround misbehaving implementation?
>
> Well, It's definitely behaved that way "traditionally" (where
> traditionally means on any platform I've had to use mmap() on), and
> the manpage is less than specific about what "cannot be used" means.
> SUSv3 has this to say:
>
> > If a MAP_FIXED request is successful, the mapping established by mmap()
> > replaces any previous mappings for the process' pages in the range
> > [pa,pa+len).
>
> Again, it's very hazy, but it at least explicitly mentions that
> MAP_FIXED may replace previous mappings.
>
> Really, MAP_TRYFIXED is just a hack to avoid the trouble the kernel
> goes to in an effort to avoid mmap() and sbrk() from stomping on
> eachother. It doesn't matter in Linux because sbrk() has much less
> effect on things. (It's not a sytem call) I'd imagine it better to add
> an explicit flag for this corner case than to change the behaviour of
> existing applications. Apps using MAP_FIXED already are likely to be
> quite sensitive to such a change.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>