From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:38:28 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 8BDAD16A41C; Fri, 17 Jun 2005 18:38:28 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A3643D1D; Fri, 17 Jun 2005 18:38:27 +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 j5HIcPrf026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 20:38:26 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B3189E.6030408@portaone.com> Date: Fri, 17 Jun 2005 21:38:22 +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> In-Reply-To: <34cb7c840506171121cd0437f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/944/Thu Jun 16 23:33: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: Fri, 17 Jun 2005 18:38:28 -0000 Peter Edwards wrote: > On 6/17/05, Maxim Sobolev wrote: > >>Peter Edwards wrote: >> >>>Y'all, >>> >>>I wanted to run a substantial windows app using "wine", and failed >>>miserably. Looking around, it appears to be an acknowledged fact >>>that wine is borked on FreeBSD, so I did some hacking about. >>> >>>The problems I found are centered around address space allocation: >>>Wine is inevitably somewhat sensitive to address space layout, >>>seeing as it has to present the Win32 binaries with a reasonably >>>familiar environment. (All this assumes standard kernel, etc. Fixed >>>addresses are the order of the day) >>> >>>Problem 1: >>> >>>When starting up, Wine needs to mmap stuff at address 0x80000000, >>>but does so without using MAP_FIXED: I think the intention is that >>>the code involved should be "best effort" to map to the hint address >>>supplied to mmap(), rather than an all-or-nothing thing. >>> >>>FreeBSD's mmap sees this as an address in the data segment (see >>>problem 2 below), and shifts the hint along to an address past >>>there. There appears to be a MAP_TRYFIXED flag that wine uses on >>>some systems that affords the hint more weight, which is pretty >>>trivial to implement (see wine_mmap.txt). That was enough to get >>>my app running, but not for long. >> >>Well, there is really no point of adding another MAP_TRYFIXED flag, >>since 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? -Maxim