Date: Sat, 18 Jun 2005 18:26:35 +0300 From: Maxim Sobolev <sobomax@portaone.com> To: Peter Edwards <peadar.edwards@gmail.com> Cc: Peter Edwards <peadar@freebsd.org>, current@freebsd.org Subject: Re: Towards a working "wine". [long] Message-ID: <42B43D2B.2060900@portaone.com> In-Reply-To: <34cb7c8405061716327ca4c6d7@mail.gmail.com> References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42B43D2B.2060900>