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>