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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
-----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 address
> > 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 break
> 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
mmap the memory for the libraries, but the addresses that are mmap'ed seem to
seem to overlap with memory that the current pthread implementation want to
mmap for the "red zone" when wine tries to create a thread. It can't mmap
the "red zone" addresses since all those address mapping where gobbled up
before the thread launched.
I'll try to figure out a way to maybe leave a space for the "red zone" and see
if that works.
Someone who actually knows what they are doing should probably take a look.
- --
Anish Mistry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFBGQuRxqA5ziudZT0RAv0VAJ0bL3c9McGSCjtXLucNuIwJRWkt7QCdG6Uh
jJeycc2sW1sb4fFOsJ+vT/k=
=/uWq
-----END PGP SIGNATURE-----
[-- Attachment #2 --]
--- 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) {
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408101353.22714.mistry.7>