Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Aug 2004 13:53:14 -0400
From:      Anish Mistry <mistry.7@osu.edu>
To:        John Birrell <jb@cimlogic.com.au>
Cc:        freebsd-current@freebsd.org
Subject:   Re: FreeBSD and wine mmap
Message-ID:  <200408101353.22714.mistry.7@osu.edu>
In-Reply-To: <20040804223937.GA99521@freebsd3.cimlogic.com.au>
References:  <200407271731.12282.mistry.7@osu.edu> <200408041828.26762.mistry.7@osu.edu> <20040804223937.GA99521@freebsd3.cimlogic.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408101353.22714.mistry.7>