Subject: Re: Wine & NetBSD?
To: Todd Vierling <email@example.com>
From: Bang Jun-Young <firstname.lastname@example.org>
Date: 11/21/2001 14:21:54
On Tue, Nov 20, 2001 at 05:44:08PM -0500, Todd Vierling wrote:
> On Wed, 21 Nov 2001, Bang Jun-Young wrote:
> : > In particular, the straw example you gave had a completely bogus
> : > expectation: you thought that mmap(0x50000000, ...) without MAP_FIXED
> : > would remap 0x50000000. It *cannot*, from the citation I gave:
> : I know it cannot, but why can we never mmap at 0x500000 while we can at
> : 0x50000000? This is definitely not Wine's fault.
> You can map anywhere you wish *as long as you specify MAP_FIXED*, and as
> long as the address is not in unusable memory (there are some memory ranges,
> such as stack, break, kernel-reserved, and MMU-inaccessible blocks on
> different architectures).
> If you don't specify MAP_FIXED, you cannot expect anything from the result
> except a mapping to an arbitrary memory location. If you even get close to
> the address you request without MAP_FIXED, you're simply lucky.
If so, we don't have to check with MAX(). Just
addr = round_page((vaddr_t)p->p_vmspace->vm_daddr + MAXDSIZ));
would be enough. Also, the comment is wrong:
- * not fixed: make sure we skip over the largest possible heap.
0x400000 doesn't belong to the heap. I guess he didn't consider the
address range below vm_taddr.
- * we will refine our guess later (e.g. to account for VAC, etc)
I believe it's time to refine it.
> Wine is still broken, and only Wine can be fixed to work correctly. Now, if
> it needs an *extension* to mmap() in order to indicate some failure state
> that it's looking for, we can perhaps talk about that. But the current
> NetBSD kernel semantics are already correct and do not need to change.
I'm not saying that NetBSD semantics is wrong. I'm saying the patch is
Bang Jun-Young <email@example.com>