From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 15:26:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72D4016A41C; Sat, 18 Jun 2005 15:26:44 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC07643D4C; Sat, 18 Jun 2005 15:26:43 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j5IFQdlI046187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jun 2005 17:26:40 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B43D2B.2060900@portaone.com> Date: Sat, 18 Jun 2005 18:26:35 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> In-Reply-To: <34cb7c8405061716327ca4c6d7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/945/Sat Jun 18 11:51:33 2005 on www.portaone.com X-Virus-Status: Clean Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 15:26:44 -0000 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. > > >