Towards a working "wine". [long]
Maxim Sobolev
sobomax at portaone.com
Sat Jun 18 15:26:44 GMT 2005
Then at least manpage should be fixed to match actual behaviour I think.
-Maxim
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.
>
>
>
More information about the freebsd-current
mailing list