Fwd: Re: FreeBSD and wine mmap [PATCH]

看板DFBSD_kernel作者時間21年前 (2004/08/20 08:02), 編輯推噓0(0推 0噓 0→)
留言0則, 0人參與, 最新討論串1/1
--Boundary-00=_OzJJB+EDa/L7ReR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This was posted to -current@ last night. I have not tried this on DFly sin= ce=20 I imagine it will not apply cleanly as-is, and I don't trust my skills enou= gh=20 to try it. :) Hopefully, this will be of use to someone else. I am more th= an=20 willing to test. =2D ---------- Forwarded Message ---------- Subject: Re: FreeBSD and wine mmap [PATCH] Date: Wednesday 18 August 2004 20:51 =46rom: Anish Mistry <mistry.7@osu.edu> =2D -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, I've got a patches that are against 4-STABLE and 6-CURRENT. This fixes the mmap function so that if the upper process address space is already mmap'd it will start from the bottom and work it's way up. There is probab= ly a much better way than the simple linear search(expensive, but not too bad with the new findspace implementation), but not being a VM person I don't know. This allows wine and possibly other applications to behave how they need to. I haven't noticed any issues on either my 4.x or 6.x system. Now for the wine stuff. The 4.x patch allows for the june version of wine = to work, but newer versions seem to die with weird sig_action signals. The 6.x patch allows wine to get to the point where it threads then dies with pthre= ad errors about not being able to allocate the "red zone" I hacked up libpthre= ad just to see what would happen if we can get passed this, and wine works nicely, but the libpthread changes broke other apps so we should probably just stick with mmap change and some modifications to the wine code. I'll try to work up some wine patches to work around the pthread issue. Hopefully someone can build off this so we can get something in after the freeze. =2D - -- Anish Mistry =2D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJAekxqA5ziudZT0RAoVCAJsF1ErGopQW/iN2djYmmx7ANuU9GACgorIZ EufCVM28p/arV6u6lg4UIOU=3D =3DXi4i =2D -----END PGP SIGNATURE----- =2D ------------------------------------------------------- =2D --=20 Jonathan Fosburgh Storage Engineer UT MD Anderson Cancer Center Houston, TX=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBJJzSqUvQmqp7omYRAijpAJ9ugZhr4P+FHIfayRpNXl/vpkUkYgCdF6X0 qQ8bUUrKMjdaSH6bYoOG7rk=3D =3DV8X3 =2D----END PGP SIGNATURE----- --Boundary-00=_OzJJB+EDa/L7ReR Content-Type: text/x-diff; charset="iso-8859-1"; name="vm_mmap-wine-4-stable.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap-wine-4-stable.patch" --- vm_mmap.c.orig Tue Jul 2 16:06:19 2002 +++ vm_mmap.c Wed Aug 18 16:49:12 2004 @@ -194,6 +194,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; int disablexworkaround; @@ -264,8 +266,25 @@ */ else if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && - addr < round_page((vm_offset_t)vms->vm_daddr + maxdsiz))) - addr = round_page((vm_offset_t)vms->vm_daddr + maxdsiz); + addr < round_page((vm_offset_t)vms->vm_daddr + maxdsiz))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &vms->vm_map; + vm_map_lock(map); + addr = round_page((vm_offset_t)vms->vm_daddr + maxdsiz); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + } + vm_map_unlock(map); + + } if (flags & MAP_ANON) { /* --Boundary-00=_OzJJB+EDa/L7ReR Content-Type: text/x-diff; charset="us-ascii"; name="vm_mmap-wine-6-current.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap-wine-6-current.patch" --- vm_mmap.c.orig Thu Aug 5 03:04:33 2004 +++ vm_mmap.c Wed Aug 18 21:31:13 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,26 @@ 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 = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + } + vm_map_unlock(map); + } + PROC_UNLOCK(td->td_proc); } if (flags & MAP_ANON) { --Boundary-00=_OzJJB+EDa/L7ReR Content-Type: text/plain; charset="us-ascii"; name=" " Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Boundary-00=_OzJJB+EDa/L7ReR--
‣ 更多 syjef. 的文章
文章代碼(AID): #119J-900 (DFBSD_kernel)