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
also correct. 

Jun-Young

-- 
Bang Jun-Young <bjy@mogua.org>