From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 17:52:18 2004 Return-Path: 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 917AB16A4CE for ; Tue, 10 Aug 2004 17:52:18 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A5B43D1D for ; Tue, 10 Aug 2004 17:52:18 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7AHeTjr030294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Aug 2004 13:40:30 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Birrell Date: Tue, 10 Aug 2004 13:53:14 -0400 User-Agent: KMail/1.6.2 References: <200407271731.12282.mistry.7@osu.edu> <200408041828.26762.mistry.7@osu.edu> <20040804223937.GA99521@freebsd3.cimlogic.com.au> In-Reply-To: <20040804223937.GA99521@freebsd3.cimlogic.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_LuQGBy7Z7vDlpxv" Message-Id: <200408101353.22714.mistry.7@osu.edu> X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_34, J_CHICKENPOX_42,PATCH_UNIFIED_DIFF,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 17:52:18 -0000 --Boundary-00=_LuQGBy7Z7vDlpxv Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 August 2004 06:39 pm, you wrote: > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > Ok, so we need something like vm_map_findspace(), but for process addre= ss > > mapping? ie. pmap_findspace() that will return an address to a large > > enough free chunk? > > That's a good start, just to get something to work with. How this fits in > with the vm code and whether it is ultimately suitable in the long run is > probably up to Alan Cox. For now, just get something that (a) doesn't bre= ak > anything else; and (b) lets Wine behave the way it needs to. > > AFAIK, there are still pthread issues with Wine, but those can't be > addressed until the mmap issue has a work-around. I've got a small patch that gets by the initial problem about not being to= =20 mmap the memory for the libraries, but the addresses that are mmap'ed seem = to=20 seem to overlap with memory that the current pthread implementation want to= =20 mmap for the "red zone" when wine tries to create a thread. It can't mmap= =20 the "red zone" addresses since all those address mapping where gobbled up=20 before the thread launched. I'll try to figure out a way to maybe leave a space for the "red zone" and = see=20 if that works. Someone who actually knows what they are doing should probably take a look. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGQuRxqA5ziudZT0RAv0VAJ0bL3c9McGSCjtXLucNuIwJRWkt7QCdG6Uh jJeycc2sW1sb4fFOsJ+vT/k=3D =3D/uWq =2D----END PGP SIGNATURE----- --Boundary-00=_LuQGBy7Z7vDlpxv Content-Type: text/x-diff; charset="iso-8859-1"; name="vm_mmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap.patch" --- vm_mmap.c.orig Thu Aug 5 03:04:33 2004 +++ vm_mmap.c Tue Aug 10 13:02:09 2004 @@ -208,6 +208,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; off_t pos; @@ -276,9 +278,28 @@ if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)))) + lim_max(td->td_proc, RLIMIT_DATA)))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &td->td_proc->p_vmspace->vm_map; + vm_map_lock(map); addr = round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)); + lim_max(td->td_proc, RLIMIT_DATA)); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 2048*1024;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + +/* printf("NFND 0x%X : data : 0x%X : FF : 0x%X\n",addr,(vm_offset_t)vms->vm_daddr,(vm_offset_t)map->first_free->start);*/ + } + vm_map_unlock(map); + } + PROC_UNLOCK(td->td_proc); } if (flags & MAP_ANON) { --Boundary-00=_LuQGBy7Z7vDlpxv--